ios - 将 NSPrivateQueueConcurrencyType 子上下文与 NSPrivateQueueConcurrencyType 父上下文一起使用

Question

我在使用子上下文作为 NSPrivateQueueConcurrencyType 的便签本时遇到了问题。

我的核心数据栈是这样的:

View Controller 使用主上下文。 Worker Context 用于从 API 导入数据。我正在使用 mergeChangesFromContextDidSaveNotification 合并 Main 上下文和 Worker 上下文之间的更改。如果我将 Worker Child 上下文排除在外，一切似乎都在正常工作。

但是，我想在导入对象时将 worker 子上下文用作便笺簿。一些数据需要构建嵌套对象，如果在构建过程中某处出现错误，我只想丢弃该上下文。如果构建成功，我希望能够保存 worker 子上下文，让它将更改推送到 worker 上下文，然后 worker 上下文可以保存更改并将更改合并到主上下文。

但是，当我尝试在 Worker Child Context 中执行获取请求以进行查找或创建时，即使它是在 Worker Child Context 的 performBlock 中完成的，我也得到了多线程断言。

我不确定哪些代码片段有助于回答这个问题，但我主要担心的是我的整体方法行不通。将私有(private)队列上下文作为另一个上下文的子上下文是个坏主意吗？

编辑:

我遇到的崩溃是当工作子上下文试图执行获取请求以执行查找或创建操作时。它没有在谓词中使用任何托管对象，而是包装在 performBlockAndWait 中。我得到的解释是 'NSInternalInconsistencyException', reason: 'statement is still active' 崩溃是间歇性的，但到目前为止，它似乎只在我有嵌套的 worker 子上下文时发生。 (即我图中的 worker 子上下文将有一个自己创建对象的子上下文)

导致崩溃的获取请求总是用于查找或创建操作，因此它会尝试获取任何具有与正在导入的对象的标识符匹配的唯一标识符属性的对象。所以谓词总是类似于 "identifier in ["1234", "abc", "etc"]

正如我在评论中提到的，我最初使用的是 PSC -> Private Context -> Main Context -> Private Worker Context 设置。当工作上下文在导入数据时获取和保存时，我遇到了 UI 卡住，因此我正在尝试重构此堆栈以释放 UI。

Answer 1

显示您的提取及其谓词将有助于确定发生了什么。听起来您正在跨线程边界访问 NSManagedObject，也许在您的谓词中使用了一个？

顺便说一句，如果您将工作人员移动到主队列下，您将不需要处理消费通知。其他一切都将完全相同，但您需要处理的代码更少，出现线程问题的风险也更低。

I initially had the workers under my main queue. PSC -> Private Queue -> Main Queue -> Private Workers. I'm refactoring to the setup I'm asking about because I'm experience the UI being blocked while the worker contexts are fetching / saving for find or create imports. Is there another way to optimize performance that you would recommend other than refactoring the core data stack?

您是否运行仪器来确定该 block 来自子 MOC？在每种情况下，我都听说过这个问题，我发现它是其他问题(通常与 UI 相关)才是问题的实际来源。除非您针对错误的谓词获取 THOUSANDS 的对象，否则您应该不会感到获取失败。即使那样，也可以优化谓词来解决问题。

至于保存，您可以 A) 增加保存频率或 B) 设置私有(private) MOC 作为磁盘写入器。我更喜欢 B，这样所有的保存都保证是异步的。