IOS核心数据异步保存

Question

问题陈述

我无法异步保存服务器端数据。

结构

我正在使用以下结构的 NSManagedObjectContext 以从父到子的顺序：

1. writerManagedObjectContext (NSPrivateQueueConcurrencyType)
2. masterManagedObjectContext (NSMainQueueConcurrencyType)
3. backgroundManagedObjectContext (NSPrivateQueueConcurrencyType)

代码

我正在使用以下代码来保存数据

[backgroundManagedObjectContext performBlock:^{
    [backgroundManagedObjectContext save:nil];
    [masterManagedObjectContext performBlock:^{ // Starts blocking UI from here
        [masterManagedObjectContext save:nil];
        [writerManagedObjectContext performBlock:^{
            [writerManagedObjectContext save:nil];
        }]
    }]
}]

问题

代码保存良好。 backgroundManagedObjectContext 也异步保存。但是，masterManagedObjectContext 和 writerManagedObjectContext 都拒绝异步保存并阻塞 UI 线程。 （我知道它阻塞了 UI 线程，因为我试图执行与 Core Data 无关的操作，它们也被阻塞了。这不是持久协调器无法访问的情况）

问题

1. 上述代码阻塞主线程的原因是什么？
2. 假设我可以从任何地方调用上述代码，因为save 将在每个相应的线程/上下文中被调用，我是否正确？

任何帮助将不胜感激。

编辑

http://floriankugler.com/2013/04/29/concurrent-core-data-stack-performance-shootout/

显然冻结来自尝试传播到父 NSManagedObjectContext。这篇文章似乎回避了这样一个事实，即不可能将真正的异步保存到主要上下文中。

数据被高度链接，5MB，大约需要 40 秒才能保存到 psc。我不认为我会使用帖子中描述的并行结构，因为代码库已经很大了。如果我能利用任何策略来减少这种冻结，我将不胜感激。

Answer 1

即使backgroundManagedObjectContext 是一个私有队列上下文，它仍然会将其更改传播到masterManagedObjectContext，它是它的父级。这可能是它窒息的地方。合并子上下文中的更改仍会占用 CPU 时间，其影响在 UI 等繁忙队列中变得更加明显。

您始终可以使用 Instruments 来分析正在发生的事情。

如果您的特定用例允许，请尝试将backgroundManagedObjectContext.persistentStoreCoordinator 设置为与writerManagedObjectContext 相同的psc，而不是使其成为masterManagedObjectContext 的子代。

更好的是，使用像 MagicalRecord 这样的很棒的框架。不会使您免受此类问题的影响，但更少的代码使（可以说）更容易调试。