e-works数字化企业网  »  文章频道  »  基础信息化  »  移动应用

微信 WCDB 进化之路 - 开源与开始

2017/6/24    来源:腾讯Bugly    作者:佚名      
关键字:微信  微信 WCDB  
今天,WCDB(WeChat Database)通过了公司的最终审核,作为腾讯微信的一个开源组件分享给大家。
    我们来了
 
    今天,WCDB(WeChat Database)通过了公司的最终审核,作为腾讯微信的一个开源组件分享给大家。
 
    从WCDB初建,到不断摸索、优化,再到整理代码、文档,最终看着她在 GitHub 上静静等待着“Make Public”被按下,心情犹如看着女儿出嫁的父亲。趁此机会,正好回顾一下 WCDB 这个“微信的数据库”的成长,分享我们的心路历程,也希望以此让大家更了解WCDB。
 
    各自探索
 
    最早期的微信,各个平台除了“使用 SQLite”这个共识,基本各自为政。
 
    Android 平台由于 SDK 提供的支持尚可,而且使用 NDK 开发不便,自然选择系统 API 接口进行开发。 
 
    iOS 情况则有不同。系统提供的CoreData 学习成本很高、性能一般,并不那么好用。因此,在再三考量之下,我们决定自行封装一套接口,命名为 WCDB。
 
    iOS 上的进化之路
 
    WCDB最初的封装与FMDB类似,都是直接暴露字符串接口,让业务开发自己拼接字符串,取出数据后赋值给对应的Object。在线程管理上,则是通过线程锁,使所有线程的访问串行执行,以保证线程安全。
 
    然而,这种方式过于简单粗暴,以至于我们自己使用起来都觉得甚是烦心。
 
    胶水代码
 
    翻开业务和WCDB的粘合层,一个几十行的函数,绝大部分都是拼接SQL、处理SQLite返回的空数据和错误码之类的“裹脚布”代码。而且这种代码四处分布,字里行间都写着"Copy & Paste"。
 
    效率极低
 
    SQL基于字符串,命令行爱好者甚喜之。但对于基于现代IDE的移动开发者,却是一大痛。字符串得不到任何编译器的检查,业务开发往往心中一团热火,奋笔疾书下几百行代码,满心欢喜点下Run后才发现:出错了!
 
    静心下来逐步看log、断点后才发现,噢,SELECT敲成SLEECT了。改正,再等待编译完成,此时已过去十几分钟,心中的热火早被浇灭,还谈何效率?
 
    SQL注入
 
    随着微信业务的发展,安全问题也逐渐突显。客户端数据库虽然不像服务端数据库那么容易被坏人盯上,但在微信这么大的体量下,防贼之心绝不可无。
 
    SQL注入通常是利用SQL字符串拼接的特点,用一些特殊符号提前截断SQL,达到执行其他SQL的目的。试想这么一段代码:
 
微信 WCDB 进化之路 - 开源与开始
 
    这段封装很简单,就是将消息内容插入到数据库中。假设对方发来这么一条消息:"');DELETE FROM message;--",那么这条SQL就会被截断成三部分:
 
微信 WCDB 进化之路 - 开源与开始
 
    它会在插入一条消息后,将表内的所有消息删除。倘若微信内存在这样的漏洞,后果将不堪设想。
 
    其实反注入并不难,通过绑定参数或替换单引号为双单引号即可解决。但要在业务开发的过程时时刻刻警惕这样的风险,并不现实,毕竟人总会犯错的。
 
    卡顿频发
 
    随着微信内收发消息量的不断增长,串行的实现使得当多个线程同时并发时,就造成了相互阻塞。
 
    与此同时,微信内也产生了一些新的需求:聊天记录备份。
 
    聊天记录备份是会不断地读取手机上的聊天记录,并传输到PC/Mac微信上。换句话说,就是在单线程下会不断地阻塞数据库。这就会直接影响到用户收发和查看聊天记录。
 
    难道用户备份数据的时候,就不能使用微信了吗?显然不现实。
 
    于是,我们就让WCDB完成了一次进化。
 

本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐