我正在开发一个由 Core Data 支持的应用程序。 现在，当我在上下文中添加或删除实体时，我正在保存对象上下文。 我怕会影响性能，所以我在考虑延迟保存。 事实上，我可以一直推迟到应用程序终止。 仅在应用程序即将关闭时才保存数据是否太冒险？我应该多久调用一次对象上下文的保存？
我正在考虑让一个单独的线程处理保存：它将等待一个信号量。每次应用程序的任何部分调用 helper/util 方法来保存核心数据时，它都会减少信号量。当它降至零时，“保存线程”将执行一次保存，并将信号量增加到 a，例如 5，然后再次休眠。
有什么好的推荐吗？ 谢谢！
【问题讨论】：
您应该经常保存。保存操作的实际性能与您使用的持久存储类型有很大关系。由于二进制和 XML 存储是原子的，因此每次保存时都需要将它们完全重写到磁盘上。随着对象图的增长，这确实会减慢您的应用程序。另一方面，SQLite 存储更容易以增量方式写入。因此，虽然会在您保存的对象之上和之外编写一些内容，但开销远低于原子存储类型。无论整体对象图大小如何，仅影响少数对象的保存总是很快。
也就是说，如果您在循环中导入数据，我会等到整个操作结束后再保存，而不是在每次迭代时保存。您的主要目标应该是防止数据丢失。 （我发现用户不太关心这个！）性能应该紧随其后。您可能需要做一些工作来平衡节省频率与性能之间的关系，但您在上面概述的解决方案似乎有些矫枉过正，除非您已经确定了一个特定且重要的性能问题。
【讨论】：
#define，这样一旦你在测试中，你就可以微调你的保存频率并在 Instruments 中观察结果。
在其他答案中未提及的一个问题是，您的解决方案涉及使用后台线程，不应在另一个线程中使用的托管对象上下文上运行。通常你会为后台线程创建一个新的 MOC，但如果你保存到不同的/未修改的后台 MOC，那会破坏保存的目的。
所以你的问题的几个答案：
你真的想尽可能多地立即存钱，所以至少我的建议是节流，而不是随意设置任何计时器或倒计时。
【讨论】：
我认为最好的方法是在每个对象之后保存。如果发生诸如突然崩溃之类的事情，则不会丢失任何东西。
一些性能增强，如果你添加很多对象是为了批处理。将所有对象添加到上下文而不是保存。例如，如果您在循环中添加很多对象，这很好。你的想法是类似的，但是保存之间可能有很长的时间，程序可能会崩溃。
我不认为添加单个对象会成为性能问题。您的对象有多大，它们是否包含大量数据？
【讨论】：