我有一个 iPad 应用程序，核心数据中有相当多的文本数据(大约 75MB)。每周导入新数据。导入发生在具有自己的 NSManagedObjectContext 甚至 NSPersistentStoreCoordinator 的辅助线程上。
导入过程包含许多提取，除了一次之外，所有这些都非常高效，因为它返回大量记录(这可能可以稍微优化一点，但实质上不是如此。)不幸的是，在这段时间进行大量提取时，主 UI 会被阻止(因为它还必须从存储中提取并且提取会被延迟)。
我在不同的点测试了导入过程，以确认它确实在后台线程上。我对代码进行了双重检查，以确保使用具有单独协调器的导入上下文。 undomanager 为零并且导入上下文经常重置。
即使使用单独的 NSPersistentStoreCoordinator，后台中的大型提取请求是否仍然可能阻止主线程上的提取请求，或者我做错了什么？
最佳答案
后台线程上的操作不会阻塞主线程，但会消耗大量内存，导致主线程无法继续高效运行。
听起来你的大量后台获取“返回大量记录”正在内存中创建一个大型事件对象的对象图，这正在消耗你的内存。内存不足会阻碍主线程。
使用 Instruments 来分析您的内存以进行确认。
解决方案是仅将实际存在的、已填充的对象保留在内存中，这是您绝对必须的。您可以使用较小的提取、作为错误提取、提取属性或作为托管对象 ID 提取以及类似的方法来减少内存占用。
此外，请确保下载数据本身的网络操作不会占用内存或周期。
关于cocoa-touch - 核心数据: Can a Large Background Fetch Block Fetch Request on the Main Thread?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7471326/