新年新语言,WCDB Swift

01-03 08:07

WCDB 作为微信的终端数据库,从 2017.6 开源至今,共迭代了 5 个版本。我们一直关注开发者们的需求,并不断优化性能,新增如全文搜索等常用的功能。而这其中,呼声最高的莫过于 对 Swift 的支持。

WCDB ObjC 版本的实现中,由于引入了 C++ 代码,并不能直接 bridge 到 Swift。因此,我们从 9 月份开始就着手使用原生的 Swift,重写 WCDB。并于 10.10 和 11.8 分别在开发者群内发布了 alpha 和 beta 版进行测试。

今天,终于可以正式发布 WCDB Swift 的第一个正式版本了。

WCDB Swift 约有 1.5w 行代码,使用 Pure Swift 编写,几乎不包含 Cocoa 的代码。且与 ObjC 版保持完全一致的功能。

模型绑定

WCDB Swift 的模型绑定,基于 Swift 4.0 的 Codable  协议实现。通过建立 Swift 类型与数据库表之间的映射关系,使得开发者可以通过类对象直接操作数据库。

语言集成查询

语言集成查询深度结合了 Swift 和 SQL 的语法,使得纯字符串的 SQL 可以以代码的形式表达出来。结合代码提示及纠错,极大地提高开发效率。

同时,由于 Swift 的语法 比 Objective-C 更加简洁,并有更强大的范型和类型推导,使得 WCDB 接口不仅更易编写,而且更易读易维护。

类似  Sample.Properties.identifier > 0 的语法,其返回值并不为 Bool ,而是语言集成查询的 Expression 对象,WCDB 会根据这个语句,去进行 SQL 的查询。同时,通过类型的定义,Swift 即可推导出 WCDB 查询的结果为 Sample 类。

语言集成查询同时内建了反注入机制,可以避免第三方从输入框注入 SQL,进行预期之外的恶意操作。

深入 SQLite 源码的性能优化

WCDB 基于 SQLite 开发,我们在 之前的文章介绍过其对 SQLite 源码进行的性能优化 ,以适配移动终端的场景。同样地,这部分优化 Swift 版本也能享受到。

线程安全且并发

WCDB Swift 不仅可以安全地在任意线程进行数据库操作,且其内部会智能地根据操作类型调配资源,使其能够并发执行,进一步提升效率。

加密

基于 SQLCipher 的加密机制,可以为客户端数据安全提供一定程度的保障。

字段升级

数据库模型与类定义绑定,使得字段的增加、删除、修改都与类变量的定义保持一致,不需要开发者额外地管理字段的版本。

模型绑定中新增了 newColumn  字段,该字段也会被自动创建到数据库表中,开发者不需要手动管理。

全文搜索

WCDB Swift 提供简单易用的全文搜索接口,并包含适配多种语言的分词器,使得数据搜索更精准。

损坏修复

内建的修复工具可以在系统错误、磁盘故障等情况下,尽最大限度地将损坏的数据找回并导出。

Pure Swift

模型绑定对语言的依赖性很大。由于 ObjC 其强大的消息转发机制,使得 WCDB 实现起来并没有太大的问题。然而,动态性却恰恰是 Swift 一直为人诟病的地方。

最省事的解决方案就是,直接引入 Cocoa,所有的问题都将不再是问题。然而,这并不是我们所期望的。

理性分析可以得出,一方面,全面的动态化会拖累 Swift 的性能,另一方面,这也会使得 Swift 的原生类型难以享受到模型绑定。

但我们的理由可能更感性一些 --- 情怀。称之为强迫症也好,代码洁癖也罢,Swift with Cocoa 总让人心里有那么一丝别扭。因此,我们决定寻找 Swift 原生的解决方案。

WCDB 的模型绑定对语言有两点依赖:

1. Accessor。ObjC 版本使用  selector  的 IMP  指针,使得 WCDB 可以获取变量的值,并插入到数据库中,或从数据库中获取数据写入到变量。

2. 数据库字段的映射。ObjC 版本使用宏定义,使得 WCDB 可以通过 className.propertyName  的方式进行语言集成查询的操作。

KeyPath

我们最初盯上的是 Swift 的 KeyPath  的机制,它通过 \  的语法,可以直接对变量进行读写操作,且语法上也与 className.propertyName  类似。

一个难题是, KeyPath  在不引入 Cocoa 的情况下,是并不提供 property 的名称,这就无法通过 KeyPath  直接映射数据库的字段。

Swift 也有一个相关的 SR 在讨论这个问题。

显然,我们不可能等待这个特性实现了再去做 WCDB Swift。因此我们尝试使用“不常规”的方法,获取到 KeyPath  对应的 property 名称。

Mirror  是 Swift 里的反射类型,它可以遍历每个变量,获取其名称和值,但不能对变量写入数据。因此我们可以通过 KeyPath  对变量设一个独一无二的特征值,然后再通过 Mirror  遍历变量,导出与特征值相同的 property 名称。

这个“不常规”的用法在大部分情况下能够生效,但对于 class  和 struct  相互嵌套的变量,容易因为内存混乱导致 crash。

Codable

KeyPath  的方案不够完善的情况下,我们转投了 Codable  协议。它是 Swift 4.0 新增的特性,本质是编译前根据定义生成代码,以完成序列化和反序列化的任务。

对应到 WCDB,将数据库的字段读写到变量中,其本质就是一个序列化和反序列化的过程,而  CodingKeys  也可能可以用于语言集成查询中的字段映射。

然而,由于这个特性还很新,还没有太多文档对其进行深入介绍,尤其是自定义 Encoder  和 Decoder  这部分。

所幸的是,Swift 本身就是开源的。因此,我们参考 swift-corelibs-foundation 中的 JSONEncoder  和 JSONDecoder ,实现了 TableEncoder  和 TableDecoder ,并通过 CodingKeys  的定义,映射数据库中的字段。

最终维护了我们对 Pure Swift 的坚持。

微信也转向 Swift 开发了吗?

相信这会是大家非常关心的问题。然而,很遗憾,目前还没有。不仅微信,国内外大部分 app 都还没有完全转向Swift,但显然这是个趋势。

Google 在 11 月 fork 了 Swift。

大家犹豫不定的原因都大同小异:ABI不稳定,需要将二进制打包进去,增大app体积;某些方面性能还不够好,而且现在多数是与 ObjC 混编,将进一步拉低性能 等等。

而这其中一个很重要的原因就是,Swift 的基础设施还不完善,还难以支撑其大型 app 的开发。而 WCDB Swift 就是这类基础设施之一。

因此,先有 WCDB Swift,未来才有用 Swift 编写微信的可能,这逻辑没毛病。

另一方面,没有微信的上线机制的保护和庞大的用户量的验证,我们需要确保 WCDB Swift 的稳定性。因此,在 WCDB Swift 的第一版本,我们就提供了相对完善的测试用例,用例的 代码覆盖率为 91.34% ,能够触达绝大部分使用场景。

更多 WCDB Swift 的教程文档、代码样例,包括源码,都可以点【阅读原文】,或直接到 Github 的 Tencent/wcdb 了 解。

我们一起期待 Swift 成为开发者的首选的那一天。

原文链接:https://mp.weixin.qq.com/s/mf-JDZrTHAS0ViJBbpC1cA?utm_source=tuicool&utm_medium=referral
标签: Swift 数据库
© 2014 TuiCode, Inc.