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