骑猪兜风

iOS的开源ORM Shark:以高性能、多线程的开发去替代Core Data

骑猪兜风 2016-07-05 09:44:09    200817 次浏览

  英文原文:Open-Source Shark ORM for iOS Aims to Replace Core Data for High-Performance, Multi-Threaded Apps

  Shark 是一种新近出现的用于 iOS 的开源 ORM 框架,目的在于通过提供高性能与线程安全功能,成为 Core Data 框架的易用替代者。InfoQ 访谈了 Spark 的创立者,Adrian Herridge。

  正如 Herridge 所述,Shark 源于对 DBAccess 的开发经验。DBAccess 是 Herridge 前期开发的一种用于 iOS 的 ORM,并得到了 InfoQ 至始至终的关注。Herridge 谈及,Shark“具有与 DBAccess 近乎一致的操作规范”,仅是由于版权的原因,Shark 大范围地重构了其代码库。尽管 DBAccess 是非开源的,但它还是得到了一定规模的应用。Herridge 根据开发人员间的相互交流情况、CocoaPod 的度量情况和 Stack Overflow 的提问情况,估计当前大概有 700 个左右的 App 使用了 DBAccess,这些应用合计约有 12,000 次下载。

  据其创建者所言,Shark 的一个强大之处在于其易用性。下面的代码段展示了如何去创建对象,执行查询并通过 ORM 更新对象,这也是使用 Shark 的 FLUENT API 的一个典范。

  Shark 的后台数据库使用 SQLite,支持开发人员执行带有连接和子查询的 SQL 语句。Herridge 指出,这对于开发人员优化应用性能而言是一个十分重要的特性。

  线程安全性将会是另一个受 Core Data 开发人员欢迎的特性。该特性使得在“任何场景下”,Shark 所返回的对象得以跨线程使用。

  Shark 提供的其它卓越特性包括:

  • 事务;
  • 时间模型;
  • 列级加密;
  • 支持批处理操作;
  • 对象域,支持对对象管理方式的控制。

  为对 Shark 具有更深的了解,InfoQ 与 Herridge 进行了如下访谈。

  你是如何实现从 DBAccess 项目向 Shark 项目的转变的?

  “我们想要开源 DBAccess 的动机,纯粹因为我们只有有限的开发时间。越来越多的开发人员联系到我们,并提出在 DBAccess 项目中添加一些新特性的需求。这些特性我们认为是完全合理的,但是在项目之初并未被我们所考虑到。鉴于项目主版本的开发已经作为一个阶段而结束了,并且该主版本已对我们的所有项目可用了,因此对于项目改进工作我们只能分配很少的时间,而且这些改进对于我们的产品而言并没有任何明显的收益。当前,已有一个足够规模的社区愿意为该项目做出贡献。相对于原项目,我们希望能向更好的方向推进该产品。自开源项目发布以来,我可每周花费至少 8 个小时在其中,当前对项目的服务支持请求已经显著减少了。

  但是我们无法获准去发布我们已经编写好的代码。因而在与我们的 CEO 讨论之后,我们确定了一个合适的变通方案,就是重写该 ORM 的代码,并给予新项目一个完全不同的名字。就这样代码重写工作启动了。起始我们将原始代码拿来并重构到不同的源文件中,这使得代码更加模块化。然后对于代码中相对复杂的部分,我们将这些部分从源代码中剥离出来,并在稍后的工作中对这些部分进行重写(例如查询缓存管理器和共享内存系统)。令我们失望的是,这样做的结果对性能改进甚微。

  其后,当我们已完成了代码库重构,就开始重写每个函数,并使其与原函数的代码完全不同。这个工作看上去是对每个人的个人时间的一种浪费,但这样做是十分必要,这使得 Shark 项目与原始项目完全不同,避免了将来可能导致的任何问题。但是在工作复审时,我们发现相对于原来的代码库,新项目依然存在着一些细微的相似之处。注意这里我说的不是一样,而是相似。进而我们做了更进一步的协同开发,去实现代码的模块化,以及有易于二次开发的代码分割。大约在此后一年,尽管还是存在相似之处,新项目已经成为了一个完全不同的代码库。我们已具有了持续测试新方法输入输出的能力,可确保项目的完整性及与 DBAccess 的兼容性。”

  为什么没有选择 Swift?

  “这个问题很难回答。Swift 很明显是未来的发展方向,并且 Swift 具有足够丰富的特性去完成一个开发任务。但溯本追源,DBAccess 需要是静态库,这使得如有必要 App 可以向后兼容到在 iOS6 上使用。

  在我们启动项目移植时,且就我当时所知,Swift 是不能被包含在静态库中的。但是这个原因与我们没有选择 Swift 是毫不相关的。因为我们当时还达成一个共识,就是开发中只是去使用 XCode 7 提供的项目模板,而避免去“破解”使用框架所提供的对象。这里 XCode 模版是生成面向 iOS 8 及以上版本的动态框架。

  该做法中仍然存在的问题是,如果项目是用 Swift 编写的话,那么 Objective-C 对象就不能继承于 Swift 基础类,该基础类从本质而言在我们的项目开发中是无法回避的。

  现在代码库已经很好地重构了,我们也面对用 Swift 编写其中大部分,并最终整个代码库的工作,尤其是考虑到 Swift 已经是很明显是可取的发展趋势。当前我们已在顶层 Swift 对象实现上启动了工作,以启用对所有 Swift 标准数据类型的持久化。”

  与 DBAccess 项目相比,Shark 当前的成熟度如何?

  “由于 Shark 采用了按函数依次迁移和模块化的方法构建,我们可对其进行持续测试,整个代码库很少处于不可编译的状态。考虑到 Shark 项目是基于前期已构建的代码,并且实现了覆盖面更广的测试,虽然它是一个新的项目,但是在很多方面比原 DBAccess 项目更加可靠。Shark 已在文档上比 DBAceess 更进一步,并且我们正尽可能地对其所有的特性给出更多的例子程序,更加清晰的用法。”

  在 Shark 中,还有哪些你想要强调的高级功能吗?

  "对象域管理系统是 Shark 的一个高级特性。一般情况下,所有对象是各自独立的,并且保存在不同的内存空间中,因而对一个实体的实例所产生的改变只能作用于单一对象上,不能跨越到其它实例中。我们发现在我们的应用开发中,通常情况下这种经深思熟虑的设计决是十分有用的。但是在简单添加了对象域管理功能后,与被改变实例在相同域中的实例就可同时发生改变。域仅是一个字符串值,可在任何时候发生改变,这样设计的强大之处在于,当一个网络线程完成后,为实现对绑定控制的更新而更改其原有的网络域为用户界面域时,你可以同时拥有对包含有对象的网络域和用户界面域的控制。

  优化是 Shark ORM 的另一个关键特性;我们具有用于查询优化的常规工具。为实现更快的数据集检索,可添加索引以及 COUNT、SUM 和 DISTINCT 操作到任何类中。为减少查询时间并降低内存使用,可使用限制查询中检索到的属性个数的功能。这样其余的属性值可不急于进行加载,直至有必要之时。为允许在开发中截断慢的查询,并查看查询计划,可添加委派代理的方法。这样开发人员可以调整和估量任何已做改进的情况。”

内容加载中