核心数据：父上下文阻塞子

Question

我正在使用核心数据的应用程序中进行一些后台处理。后台处理在子 managedObjectContext 上完成。上下文初始化：

appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate

// the moc in appDelegate is created with .MainQueueConcurrencyType
mainThreadMOC = appDelegate.managedObjectContext!
backgroundMOC = NSManagedObjectContext(concurrencyType:NSManagedObjectContextConcurrencyType.PrivateQueueConcurrencyType)
backgroundMOC?.parentContext = mainThreadMOC

后台处理方式如下：

// download all new transaction log entries
func syncItems() {

... set up the query object for parse

let moc = CoreDataStore.sharedInstance.backgroundMOC

// perform download
moc?.performBlock( {
    self.runQuery(query)   // Download stuff und do some core data work
    })
}

调试器显示块内的所有工作确实都在后台线程中。

当我从主线程调用此函数并立即使用冗长的核心数据操作阻塞主线程（用于测试目的）时，我看到后台线程停止并且仅在主线程空闲时继续执行。

// this is called from a view controller in the main thread

syncItems() // should start to work in background
for i in 0...200 {
    // do some core data work in main thread
}
// syncItems starts to work after the blocking for-loop ends.

为什么会这样？

Answer 1

不要使用父子上下文设置。

父子上下文对于任何事情都不是一个好方法。只需使用一个简单的堆栈：两个上下文和一个共享的持久存储协调器。

父子上下文只会增加很多混乱，而不会给您带来任何好处。这是一个非常被误解的概念。我希望像 mzarra 这样的人会停止鼓吹这种设置。这是对社区的伤害。

如果您的背景上下文是主上下文的子上下文，则无论何时需要保存背景上下文，您都必须锁定主上下文和背景上下文。这会阻止 UI。您必须第二次锁定 UI，才能将这些更改从 UI 传播到 PSC。如果您使用背景上下文，则必须将更改合并到主上下文中，但您只会为当前在该上下文中注册的那些对象工作。如果您添加了新对象，或者更新/删除了当前未注册（引用）的对象，则基本上是无操作。

Answer 2

当你在评论中说“在主线程中做一些核心数据工作”时 工作访问mainThreadMOC？

听起来可能主线程工作正在锁定runQuery 需要访问的东西。

尝试将阻塞主线程的测试繁忙工作更改为不访问核心数据的东西（NSThread.sleepForTimeInterval 应该这样做），看看是否让后台runQuery 工作。

如果这是问题所在，您需要将主线程工作重构为不会阻塞 runQuery 中发生的任何事情的东西。

Answer 3

我怀疑你的问题是双重的，即使你是为了测试目的，你的

冗长的核心数据操作

在主线程上阻塞了 UI，根据您的定义，您的 backgroundMOC?.parentContext = mainThreadMOC。

我建议为您的多个NSManagedObjectContexts 创建一个更健壮的结构。

我建议您按照this answer 中列出的步骤进行操作。

此外，您还可以专门创建一个额外的 MOC 来管理您的 runQuery...

discreteMOC = NSManagedObjectContext(concurrencyType:NSManagedObjectContextConcurrencyType.PrivateQueueConcurrencyType)
discreteMOC?.parentContext = backgroundMOC //MOCprivate in my previous answer. 

希望这会有所帮助。

Answer 4

关于父母的情况，不幸的是，我上次检查文档时相当简陋，在网上你会发现几乎每个人都颠倒了流程。早在 2011 年左右，有一次关于 Core Data 的 WWDC 会议，一切都变得清晰，如果你仔细查看 API，它就会开始变得有意义。

孩子不是背景上下文 - 它是主要上下文。孩子是您通常与之交互的上下文。父级是背景上下文。

子级将更改推送给其父级。这就是为什么父级有一个persistentStoreCoordinator，而子级有一个parentContext（它不需要一个persistentStoreCoordinator）。

因此，子项是您的主要上下文，位于主 (UI) 队列中。它将更改保存到其父级中。这发生在内存中（快速 - 让 UI 尽可能响应）。

然后，父上下文通过其 persistentStoreCoordinator 将其更改保存到持久存储中。这就是父母在私人队列中的原因。

lazy var managedObjectContext: NSManagedObjectContext = {
    let parentContext = NSManagedObjectContext(concurrencyType: .PrivateQueueConcurrencyType)
    parentContext.persistentStoreCoordinator = self.persistentStoreCoordinator

    let managedObjectContext = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
    managedObjectContext.parentContext = parentContext
    return managedObjectContext
}()

还有其他优化，例如将 .undoManager 设置为 nil，但这种通用架构完美适用于后台保存。

您可能还想放入一个接收完成块/闭包的保存方法，立即保存在您的子队列中（如前所述，它只保存到父队列中），然后调用您将拥有的 parentContext 的 performBlock 方法它将（在其私有队列上）保存到底层持久存储中（相对较慢，但现在非阻塞），然后调用您的完成块/关闭（您已经使用 GCD 设置它以在主队列上运行，或者否则，您在父级的 performBlock 方法中从那里回调到主队列。

如果您不反转架构，一切都会完美到位。我不确定它是如何在网上开始的，但这几乎是一个普遍的错误。

祝你好运。