我正在优化我的第一个iOS应用程序，然后才能进入商店，并注意到看似花费更多时间的方法。我有一个相当简单的主 - 细节应用程序，其中Core Data SQLite中的实体显示在UITableView中，然后点击一个会打开一个详细视图，用户可以将其标记为收藏（设置{{1}将该对象标记为BOOL。一旦他们点击他们的收藏夹按钮，我就会调用YES以确保他们的更改立即得到反映，如果是非计划终止等，
在我的iPhone 4S上进行测试时，此[NSManagedObjectContext save]操作目前大约需要205毫秒。数据库中有大约4,500个条目，每个条目都有一些字符串和一些布尔值（包含在save s中）。
第一个问题：是否需要200ms来进行此更改？我只设置一个布尔值，然后保存上下文，但我之前从未使用过Core Data，所以我没有知道这是否正常。
第二个问题：我正在使用的代码如下 - 我是否在代码中做错了以使该方法执行这么长时间？
NSNumber也许我一点也不担心（我仍然是一个相对较新的程序员），但从更广泛的角度来看，200毫秒足以让我至少尝试解决这个问题，对吗？ ：）
答案 0 :(得分：1)
考虑UIManagedDocument。它会自动处理后台环境中的保存。如果您使用的是iOS 6，我特别推荐它。如果您没有传递对象ID，或者与其他上下文合并，那么您应该可以非常轻松可靠地使用它。
您的简单用例似乎是为它量身定制的。
答案 1 :(得分：0)
1）保存一次布尔值变化需要200 ms吗？
是的，这可能需要很长时间。您正在执行IO操作并根据documentation：
当Core Data保存SQLite存储时，SQLite只更新存储文件的一部分。丢失部分更新将是灾难性的，因此您可能希望确保在应用程序继续之前正确写入文件。不幸的是，这样做意味着在某些情况下，即使对SQLite存储进行一小部分更改也可能比保存到XML存储要花费更长的时间。
-
2）我在代码中做错了什么让方法需要这么长才能执行？
没有。你正在保存到商店（假设你没有父语境）。
-
3）200毫秒足以让我至少尝试解决这个问题吗？
是。对于人类来说，200毫秒是一个值得注意的时间。您可以尝试在后台执行保存，但根据documentation，这是不安全的。或者，将其移动到整个对象编辑的末尾。
我的建议是阅读并了解您是否可以在上下文体系结构（CoreData堆栈结构）中做出一些妥协。
根据我的经验，在后台保存并不是那么糟糕。