在嵌套的 NSManagedObjectContext 中缓慢删除和保存

Question

在我的应用程序中，我有一个“主”NSPrivateQueueConcurrencyType 上下文，它充当视图控制器依赖和传递的 NSMainQueueConcurrencyType 上下文的父级。我想这样做是为了利用异步保存（这个应用程序使用 iCloud 和 Core Data 并且保存做了很多工作来导出无处不在的日志）。设置类似于this article底部提到的Zarra方法

应用内的保存通常如下所示：

[context save:nil];
[context.parentContext performBlock:^{
     [context.parentContext save:nil];
}];

这似乎适用于小型编辑/更新，但我对删除许多对象时看到的内容感到困惑（例如，删除具有数百个与之相关的任务对象的项目）。

在这种情况下，保存是异步的，但看起来主线程进入了信号量等待情况（如我暂停调试器时所见）并且在后台私有之前被有效阻止（我无法在 UI 中滚动） context 完成保存。

实际上，我只是注意到滑动删除单个对象会导致明显的延迟，尽管有这种异步保存模式，所以看起来应用程序中的所有删除都很慢。

如果，或者，我分配一个新的NSPrivateQueueConcurrencyType 上下文，将其持久存储协调器设置为 AppDelegate 中的主 PSC，并执行删除和保存，它仍然做了很多工作，但 UI 永远不会被阻塞（但是我不得不担心协调上下文，在主上下文中重新获取）。

任何想法我可能做错了什么，或者你也看到过这种行为？

Answer 1

删除可能需要很长时间。他们必须修复所有的关系。在进行大量删除时，您应该做几件事。

首先，为什么在后台发生删除时您的 UI 会阻塞？因为该后台线程确实忙于执行删除块，并且您的 UI 正在尝试获取以更新数据，同时删除正在发生。

运行实际工作的线程是由一个先进先出队列管理的，所以如果你给它一个大的任务去执行，它在长时间运行的任务完成之前将无法执行其他任务。

您可能正在使用 FRC，它正在尝试在对象和关系发生变化时获取更新。

如果您有大量删除，您可能需要更改您的提取，以便在删除发生时仅查看当前 MOC 中的数据。删除完成后，您可以告诉 fetch 请求返回到 store 本身的查询。

此外，当删除大量内容时，最好在自动释放池中的单独线程中以小块的形式进行。从该后台线程中，一次删除小块，并使用performBlockAndWait 执行此操作。这样，您就不会使用删除请求加载工作线程的队列，并且您的 UI 线程可以处理其请求。更快。

或者，您还可以使用 GCD 的高级功能来拥有一个高优先级和低优先级队列，用于将工作提供给工作线程。您可以将写入放在低优先级队列中，将读取放在高优先级队列中。