新年新语言，WCDB Swift 冷不防 2022-06-02 04:21 321阅读 0赞 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 类型与数据库表之间的映射关系，使得开发者可以通过类对象直接操作数据库。 ![1.png][] **语言集成查询** 语言集成查询深度结合了 Swift 和 SQL 的语法，使得纯字符串的 SQL 可以以代码的形式表达出来。结合代码提示及纠错，极大地提高开发效率。 同时，由于 Swift 的语法 比 Objective-C 更加简洁，并有更强大的范型和类型推导，使得 WCDB 接口不仅更易编写，而且更易读易维护。 ![2.png][] 类似 Sample.Properties.identifier > 0 的语法，其返回值并不为 Bool，而是语言集成查询的 Expression 对象，WCDB 会根据这个语句，去进行 SQL 的查询。同时，通过类型的定义，Swift 即可推导出 WCDB 查询的结果为 Sample 类。 > 语言集成查询同时内建了反注入机制，可以避免第三方从输入框注入 SQL，进行预期之外的恶意操作。 深入 SQLite 源码的性能优化 WCDB 基于 SQLite 开发，我们在[之前的文章介绍过其对 SQLite 源码进行的性能优化][SQLite]，以适配移动终端的场景。同样地，这部分优化 Swift 版本也能享受到。 **线程安全且并发** WCDB Swift 不仅可以安全地在任意线程进行数据库操作，且其内部会智能地根据操作类型调配资源，使其能够并发执行，进一步提升效率。 **加密** 基于 SQLCipher 的加密机制，可以为客户端数据安全提供一定程度的保障。 **字段升级** 数据库模型与类定义绑定，使得字段的增加、删除、修改都与类变量的定义保持一致，不需要开发者额外地管理字段的版本。 ![3.png][] 模型绑定中新增了 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 类似。 ![4.png][] 一个难题是，KeyPath 在不引入 Cocoa 的情况下，是并不提供 property 的名称，这就无法通过 KeyPath 直接映射数据库的字段。 ![5.png][] > Swift 也有一个相关的 SR 在讨论这个问题。 显然，我们不可能等待这个特性实现了再去做 WCDB Swift。因此我们尝试使用“不常规”的方法，获取到 KeyPath 对应的 property 名称。 Mirror 是 Swift 里的反射类型，它可以遍历每个变量，获取其名称和值，但不能对变量写入数据。因此我们可以通过 KeyPath 对变量设一个独一无二的特征值，然后再通过 Mirror 遍历变量，导出与特征值相同的 property 名称。 ![6.png][] 这个“不常规”的用法在大部分情况下能够生效，但对于 class 和 struct 相互嵌套的变量，容易因为内存混乱导致 crash。 **Codable** 在 KeyPath 的方案不够完善的情况下，我们转投了 Codable 协议。它是 Swift 4.0 新增的特性，本质是编译前根据定义生成代码，以完成序列化和反序列化的任务。 ![7.png][] 对应到 WCDB，将数据库的字段读写到变量中，其本质就是一个序列化和反序列化的过程，而 CodingKeys 也可能可以用于语言集成查询中的字段映射。 然而，由于这个特性还很新，还没有太多文档对其进行深入介绍，尤其是自定义 Encoder 和 Decoder 这部分。 所幸的是，Swift 本身就是开源的。因此，我们参考 swift-corelibs-foundation 中的 JSONEncoder 和 JSONDecoder，实现了 TableEncoder 和 TableDecoder，并通过 CodingKeys 的定义，映射数据库中的字段。 最终维护了我们对 Pure Swift 的坚持。 ![8.png][] **微信也转向 Swift 开发了吗？** 相信这会是大家非常关心的问题。然而，很遗憾，目前还没有。不仅微信，国内外大部分 app 都还没有完全转向Swift，但显然这是个趋势。 ![9.png][] > 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 成为开发者的首选的那一天。 原文地址：http://www.cocoachina.com/ios/20180103/21732.html [1.png]: /images/20220602/d988b1aab9c344ebb02218c520e0aee3.png [2.png]: /images/20220602/8256cab919e446548525cda5508dde59.png [SQLite]: http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286361&idx=1&sn=78bbcda7f41a14291ad71289e4821f71&scene=21#wechat_redirect [3.png]: /images/20220602/414e36a372a94f928b2c3aeea11c6303.png [4.png]: /images/20220602/6abbc1b57e5a40a49c6ef4d0a5dc3a81.png [5.png]: /images/20220602/0505df930d244b5d90a2f82be8b51422.png [6.png]: /images/20220602/4cff0569b2d54e5d8e2d90d13dc3b2c6.png [7.png]: /images/20220602/bb7ff60d603742c5b0cb1fa19df50843.png [8.png]: /images/20220602/4a8ec237b92443fe81fb753129549de2.png [9.png]: /images/20220602/1ee309eb3a414105ad99e41bac4a8b88.png
还没有评论，来说两句吧...