ios – 使用两个持久存储协调器进行高效的后台更新的陷阱

概述我正在寻找在后台更新一个相当大的基于核心数据的数据集的最好的方法，尽可能不影响应用程序UI(主线程)。 有一些关于这个主题的好材料，包括： > Session 211 from WWDC 2013(核心数据性能优化和调试，从大约25:30起) > Importing Large Data Sets from objc.io > Common Background Practices from ob 我正在寻找在后台更新一个相当大的基于核心数据的数据集的最好的方法，尽可能不影响应用程序UI(主线程)。

有一些关于这个主题的好材料，包括：

> Session 211 from WWDC 2013(核心数据性能优化和调试，从大约25:30起)
> Importing Large Data Sets from objc.io
> Common Background Practices from objc.io(后台核心数据)
> Backstage with Nested Managed Object Contexts

根据我的研究和个人经验，可用的最佳选择是有效地使用两个单独的核心数据栈，它们仅在数据库(sqlite)级别共享数据。这意味着我们需要两个单独的NSPersistentStoreCoordinators，每个都有自己的NSManagedobjectContext。在数据库上启用预写日志记录(默认从iOS 7开始)，在几乎所有情况下都可以避免锁定的需要(除非我们有两个或多个同时写入，这在我的场景中不太可能)。

为了进行高效的后台更新和节省内存，还需要批量处理数据并定期保存后台上下文，因此脏对象被存储到数据库并从内存刷新。可以使用此时生成的NSManagedobjectContextDIDSaveNotification将后台更改合并到主上下文中，但一般来说，您不希望在批次保存后立即更新UI。您希望等待后台作业完全完成，并刷新UI(在WWDC会话和objc.io文章中推荐)。这有效地意味着应用程序主上下文在一定时间段内与数据库保持不同步。

所有这一切导致我的主要问题，这是什么可能出问题，如果我改变了数据库这种方式，没有立即告诉主上下文合并更改？我假设不是所有的阳光玫瑰。

我在我的头中的一个具体情况是，如果故障需要满足在主上下文中加载的对象，如果后台 *** 作已经从数据库中删除该对象之间发生了什么？这是否可以发生在一个基于NSFetchedResultsController的表视图，使用batchSize获取对象递增内存？即，尚未完全提取的对象被删除，但是我们向上滚动到需要加载对象的点。这是一个潜在的问题吗？其他东西会出问题吗？我将感谢任何有关这方面的意见。

解决方法 伟大的问题！

I.e.,an object that has not yet been fully fetched gets deleted but
than we scroll up to a point where the object needs to get loaded. Is
this a potential problem?

不幸的是，它会导致问题。将抛出以下异常：

Terminating app due to uncaught exception 'NSObjectInaccessibleException',reason: 'CoreData Could not fulfill a fault for '0xc544570 <x-coredata://(...)>'

This blog post(“如何使用Core Data实现并发”一节)可能会有所帮助，但它不会涉及这个主题。我正在努力与在我正在开发的应用程序中的相同的问题，并希望阅读一篇关于它的写作。

总结

以上是内存溢出为你收集整理的ios – 使用两个持久存储协调器进行高效的后台更新的陷阱全部内容，希望文章能够帮你解决ios – 使用两个持久存储协调器进行高效的后台更新的陷阱所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。