正确使用 Core Data 多线程的 3 种方式

在#Pragma Conference 2015 会议上，Marcus Zarra，撰写过关于 Core Data 和 Core Animation 的书，叙述了三种在多线程环境下使用 Core Data 的方法并且设法解决在 2015 年应如何使用 Core Data 的问题。实际上，Zarras 说道，当用一个拥有十一年历史的技术比如 Core Data 工作时，你所面临的问题之一是有大量的信息是可用的，不过查明哪一份信息依旧精确以及哪一份不精确并不是一件简单的事。

根据 Zarras 所言，当我们知道我们仍旧有空余的 CPU 时我们应该使用多线程，那样我们可以预先处理用户接下来要使用的数据。多线程另外一个很重要的用例是通过允许用户不必等待一个冗长的操作来完成，来改进一个 app 的灵敏程度，比如网络操作。多线程几乎从来不是解决性能问题的办法并且它是一种基础设计决策，而不是一个事后的想法。

最初的方法

最初的方法是在 iOS 6 推出之前唯一可用的方法。这个方法现在依然可以使用，尽管 Zarra 建议除了在某些极端情况以外不要使用它。它基于四个主要的原则：

• 一个 _NSPersistentStoreCoordinator_(PSC) 处理所有磁盘之间的相互影响。
• NSManagedObjectContext__s (MOCs) 与 PSC 对话并且不知道对方的任何情况。
• 其中一个 MOCs 负责 UI 的更新并且在单一可信来源上起作用。
• 一个 MOC 开始意识到另一个 MOC 的变化的唯一方法是通过 merging 合并处理一个 _NSNotification_。

这个设计有一些不足之处，比如需要写很多公式化的代码，线程规则不明确会导致不定时发生崩溃以及意外线程阻塞。随着推出了 iOS 8，这些问题改善了一些。并且多亏了一个 debug flag 调试标志，Yosemite 才能在它违反 Core Data 并发模型的时候让应用程序崩溃。

艰难的方法

Zarras 称之为艰难的方法的是一个依赖于用于多进程访问 SQLite 的方法。这就意味着我们可以拥有多个 PSC，让每个 MOC 都可以拥有自己的 PSC。这会对摆脱任何锁定问题起到很好的作用并且启用几乎所有异步访问——除非你没有写相同的表以及同时把两个 PSC 排成一行。

即使有了这个设计，只用一个 MOC 来把数据反馈到 UI 是可取的。这个方法会让用 PSC 来同步数据变得艰难，因为它们不知道对方的任何情况。此外，线程和可维护性也会被损害。这个方法有趣的一面在于，这就是 iCloud 如何运作的真实写照。

最好的方法

根据 Zarra 所言，最好的办法并不是速度最快的，但它是到目前为止最简单和最可持续的方法。它依靠苹果和 iOS 6 一起推出的 new APIs ，new APIs 允许定义子 MOC 并且详细描述一个 MOC 的并发类型。Zarra 呈现的这个设计是基于 _NSManagedDocument_ 如何运作和使用的：

• 一个单独的持久性数据协调器。
• 唯一能实际访问 PSC 的一个私有的 MOC。
• 一个主要的 MOC 联合 UI，它是私有的 MOC 的子设备。
• 多个子 MOC 具体到辅助线程。

这个设计的好处是子 MOC 所有的变化会自动传送到其主 MOC 上，因此消除了合并的需求。

这个设计的主要缺陷是它速度缓慢，尽管只是慢了百分之几，Zarra 说道。它有一个很棘手的问题就是如果进行太多的异步操作，有可能会在 UI 上起连锁反应，因为其相关的 MOC 会受到序列的多重变化，这可能与另一个并不相干。

这个设计一个很重要的细节就是最好不要重复使用很便宜就能创造的子 MOC。另一方面，能用很久的子 MOC 应该与主 MOC 手动保持同步，因为变化仅仅是从子 MOC 到主 MOC 而反之则不行。

Zarra 的最后评论是使用 _NSManagedDocument_ 会锁定 UI，所以你最好做好准备。

查看英文原文： Three Ways to Get Core Data Multithreading Right

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。