托管对象上下文的最佳设置答案

【问题标题】：Best setup of managed object contexts托管对象上下文的最佳设置
【发布时间】：2019-01-10 15:39:18
【问题描述】：

我看过几个教程，建议在实现核心数据时使用两个（或更多）NSManageObjectContexts，以免阻塞主队列的UI。然而，我有点困惑，因为有些人建议将persistent store coordinator 的子上下文设置为mainQueueConcurrencyType 类型的子上下文，然后给它自己的privateQueueConcurrencyType 类型的子上下文，而其他人则建议相反。

我个人认为使用两个上下文的最佳设置是使用persistent store coordinator -> privateQueueConcurrencyType -> mainQueueConcurrencyType，然后只保存到私有上下文，并且只从主上下文中读取.我对这种设置的好处的理解是，保存到私有上下文不必通过主上下文，并且阅读主上下文将始终包括对私有上下文所做的更改。

我知道许多应用程序需要一个独特的解决方案，但这种设置可能无法使用，但作为一般的良好做法，这是否有意义？

编辑：

有些人指出，在引入NSPersistentContainer 时不需要此设置。我之所以问这个问题是因为我在工作中继承了一个使用 iOS-10 之前设置的大型项目，并且遇到了问题。我愿意使用NSPersistentContainer 重写我们的核心数据堆栈，但我不愿意花时间在上面，除非我能提前找到一个关于如何根据我们的用例进行设置的示例。

我们的大多数主要用例都遵循以下步骤：

1) 用户编辑对象（例如，将照片/文本添加到抽象对象）。

2) 创建一个对象（同步任务）以封装 API 调用以更新服务器上已编辑的对象。同步任务被保存到队列中的核心数据中，以便一个接一个地触发，并且仅在互联网可用时（因此允许离线编辑）。

3) 编辑后的对象也会立即保存到核心数据中，然后返回给用户，以便 UI 反映其更新。

使用NSPersistentContainer，在performBackgroundTask 中完成所有编写，在viewContext 上完成所有查看是否足以满足我们对上述用例的需求？

【问题讨论】：

对于iOS 10，我觉得不需要这些设置，因为从persistentContainer中你可以随时获取主上下文或后台上下文。
感谢您的评论@vivekDas。我编辑了我的问题以解决您的建议。
您是否观看过 Apple 提供的任何 Core Data 最佳实践视频？他们对这类事情充满了的建议。
@matt 我看过一些，觉得他们没有解决我的设置问题。你能推荐一下吗？
天哪，我认为今年的那个已经接近目标了。但也许不是。

标签： ios core-data grand-central-dispatch nsmanagedobject nsmanagedobjectcontext

【解决方案1】：

从 iOS10 开始，您无需担心这些，只需使用 NSPersistentContainer 为您提供的上下文即可。

【讨论】：

谢谢@trapper。请参阅我更新的问题，我在其中解决您的建议。
解决您的编辑问题；用户通过 UI 进行的任何更改都应保存在viewContext 中。对于后台发生的任何事情，请使用并丢弃newBackgroundContext - 不要让这些闲置时间超过必要的时间，或者稍后尝试重复使用相同的，只需为每个后台操作获取一个新的。