ios - CoreData 中具有多个上下文的并发性

Question

CoreData 中有几种处理并发的方法

其中之一是使用父/子托管ObjectContext，如下所示:

let mainContext = NSManagedObjectContext( concurrencyType: .MainQueueConcurrencyType)
let childContext = NSManagedObjectContext( concurrencyType: .PrivateQueueConcurrencyType)

childContext.parentContext = mainContext

另一种方法是让主上下文和子上下文都使用相同的 persistenceStoreCoordinator，如下所示:

let mainContext = NSManagedObjectContext( concurrencyType: .MainQueueConcurrencyType)
let childContext = NSManagedObjectContext( concurrencyType: .PrivateQueueConcurrencyType)

childContext.persistentStoreCoordinator = mainContext.persistentStoreCoordinator

由于我们需要在childContext上使用performBlock，然后在ma​​inContext上保存或执行fetch或任何其他操作，这两种方法之间有什么区别？

我继续阅读Florian Kugler's blog前一种方法在主线程上处理(我尝试过，但没有)，而后者是首选方法。但我看过的所有其他网站似乎都更喜欢以前的父/子上下文。

为了让事情变得更加困惑，在 RayWenderLich 的 CoreData 书中(第 10 章供引用)，他们使用了这两种方法，但没有解释原因。

Answer 1

理想情况下，有 3 个简单的规则可以在单个 persistenceStore 核心数据应用程序中实现并发。

1. 只有一个托管对象上下文 (MOC) 应附加到 persistenceStoreCoordinator，这是避免 MOC 锁定、CURD 操作解锁的基本规则。
2. 每个 MOC 都应该附加一个线程，例如主线程 MOC、后台线程 MOC。
3. 您无法通过 MOC(线程)将托管对象从一个 MOC(线程)传递到另一个 MOC(线程)，在这种情况下只需传递 ObjectID。

为了实现这三个规则，苹果引入了亲子 MOC 方法。各种帖子里有很多组合， 但每个堆栈(父子 MOC 方法)高度依赖于应用程序数据的可用性。

我已经实现了我的主要 MOC 上下文使用 persistenceStoreCoordinator，并创建了后台线程子 MOC 来进行数据同步， 以及每个 View Controller 的更多本地子 MOC，用于创建新记录屏幕。这对我来说效果很好，并在数据库上插入了 3500 条记录进行了测试。 这样做的好处是我可以通过我的主 MOC 获取更新的服务器同步数据。

我知道很少有批评者认为我会阻塞主线程，但你可以利用批量更新、删除、异步获取请求来最小化它。