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

Question

在我的应用程序中，我有一个“主”NSPrivateQueueConcurrencyType 上下文，它充当 View Controller 所依赖和传递的 NSMainQueueConcurrencyType 上下文的父级。我想这样做是为了利用异步保存(这个应用程序使用 iCloud 和 Core Data，保存做大量工作导出无处不在的日志)。该设置类似于 this article 底部提到的 Zarra 方法。

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

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

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

在那种情况下，保存是异步的，但看起来主线程进入了信号量等待状态(如我暂停调试器时所见)并且被有效阻止(我无法在 UI 中滚动)直到后台私有(private)上下文完成保存。

实际上，我只是注意到，尽管采用了异步保存模式，但对单个对象的滑动删除操作会产生明显的延迟，因此应用程序中的所有删除操作似乎都很慢。

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

知道我可能做错了什么，或者您是否也看到过这种行为？

Answer 1

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

首先，当删除在后台发生时，为什么您的 UI 会阻塞？因为那个后台线程真的忙于执行删除 block ，并且您的 UI 正在尝试在删除发生时获取更新数据。

运行实际工作的线程由 FIFO 队列管理，因此如果您给它执行一个大任务，它在长时间运行的任务完成之前将无法执行其他任务。

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

如果您有一个大的删除，您可能想要更改您的提取，以便它只在删除发生时查看当前 MOC 的数据。删除完成后，您可以告诉获取请求返回到一直查询到商店本身。

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

或者，您也可以使用 GCD 的高级功能来拥有高优先级和低优先级队列，用于将工作馈送到工作线程。您可以将写入放在低优先级队列中，将读取放在高优先级队列中。