在过去的几天里，我进行了大量研究，但我不确定当前并发核心数据的最佳实践是什么。最相关的帖子似乎是这个blog post，但鉴于this analysis 关于不同并发方法的性能，似乎带有父上下文的现代方式可能不是最好的。此外，来自 Apple 的 this example 没有实现 Apple's own concurrency guide 中提到的最佳实践，即建议不要使用默认的 NSConfinementConcurrencyType。
鉴于所有这些，用 Core Data 实现并发的最简单和最好的方法是什么？我所需要的只是一个后台线程，它可以在不挂断 UI 的情况下对 Core Data 进行一些长时间的写入。代码示例表示赞赏。
【问题讨论】：
标签： ios objective-c core-data concurrency
与往常一样，这实际上取决于您要完成的工作。
无论您实施何种架构，“长写入”都会挂起您的 UI。
写入操作在 OS 级别和 sqlite 引擎级别锁定 DB 文件（如果您使用这种存储），所有挂起的读取操作都必须等待写入结束才能完成。
最常用的优化方法之一是使用多个保存操作对数据库“加载”过程进行分段（您不应该介意，因为这发生在后台）。
所以，回答这个问题：
对您来说最简单的方法可能是使用您提到的博客文章中描述的架构（父子层次结构）。如果您发现这会导致您的 UI 出现很多“卡顿”，请尝试优化您的数据加载过程或尝试不同的架构。
使用工具在您的应用程序执行中找到“瓶颈”。
CodeData 在我所知道的每个架构中都有“怪癖”/错误，你会逐渐发现它们，这取决于你对它的使用。
【讨论】：
我的建议是使用父/子上下文模式。根据您提供的稀疏细节（例如记录数、数据总量、交付延迟等）。这似乎是最灵活且经过验证的解决方案，还可以容纳非常大的数据集。
与其他说法相反，无论“写入”到您的数据库多长时间，您都可以拥有流畅运行的 UI。显然，这就是后台线程的用途。保持 UI 流畅的机制是通过所谓的数据更改通知。您可以在不影响用户体验的情况下优雅地对这些做出反应。
您对NSConfinementConcurrencyType 的评论是正确的。正如您的源代码中所述，它是为了向后兼容而存在的，因此您可以忘记它。显然，对于并发，您希望在创建上下文时使用NSPrivateQueueConcurrencyType。
【讨论】：