在NSPrivateQueueConcurrencyType父上下文中使用NSPrivateQueueConcurrencyType子上下文

Question

我在使用子上下文作为NSPrivateQueueConcurrencyType的暂存区时遇到问题.

我的核心数据堆栈如下所示:

视图控制器使用主上下文.Worker Context用于从API导入数据.我正在使用mergeChangesFromContextDidSaveNotification来合并Main和Worker上下文之间的更改.如果我将工人孩子的背景置于等式之外,事情似乎正常.

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

但是,当我尝试在Worker子上下文中执行获取请求来执行查找或创建时,即使它是performBlock在Worker子上下文中完成的,我也会得到一个多线程断言.

我不确定哪些代码片段有助于回答这个问题,但我主要担心的是我的整体方法不会起作用.将私有队列上下文作为另一个上下文的子项是个坏主意吗？

编辑:

我遇到的崩溃是工作者子上下文尝试执行获取请求以执行查找或创建操作.它没有在谓词中使用任何托管对象,而是将其包装在一个performBlockAndWait.我得到的解释是'NSInternalInconsistencyException',原因:'语句仍处于活动状态' 崩溃是间歇性的,但到目前为止它似乎只有在我有嵌套的工作者子上下文时才会发生.(即我的图中的worker子上下文将具有自己创建对象的子上下文)

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

正如我在评论中提到的,我最初使用的是PSC - >私有上下文 - >主要上下文 - >私有工作者上下文设置.我在导入数据时工作者上下文获取和保存时遇到UI冻结,所以我试图重构这个堆栈以释放UI.

Answer 1

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

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

我最初将工作人员放在我的主队列下。PSC -> 专用队列 -> 主队列 -> 专用工作人员。我正在重构我所询问的设置，因为我遇到了当工作线程上下文正在获取/保存以查找或创建导入时 UI 被阻止的情况。除了重构核心数据堆栈之外，您还有其他推荐的优化性能的方法吗？

您是否运行过仪器来确保该块来自子 MOC？在我听说过这个问题的每种情况下，我都发现它是问题的实际根源（通常与 UI 相关）。除非您针对错误的谓词获取数千个对象，否则您不应该感受到获取的影响。即使这样，谓词也可以被优化来解决问题。

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