linux单个core的线程,正确使用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，所以你最好 做好准备 。