mergeChangesFromContextDidSaveNotification后的KVO通知

Question

我正在使用KVO来观察NSManagedObject的变化.我正在观察的NSManagedObject是主队列上的NSManagedObject上下文的一部分.

当我在后台(专用队列并发类型)上下文中更新此对象,然后将保存的更改合并到我的主队列上下文(在mergeChangesFromContextDidSaveNotification中)时,KVO通知将按预期触发.

但是,我预计通知只会触发实际更改的键路径,而不会触发NSManagedObject的所有键路径.即使它们没有改变,我也会收到对象的每个关键路径的KVO通知.

这是设计还是我做错了什么？

在苹果文档中看不到任何内容....

Answer 1

这是未记录但在 OS X 和 iOS 上观察到的行为：保存算作对整个 NSManagedObject 的更改，而不仅仅是不同元素的更改。您可以在本网站、openradar.appspot.com 等网站上找到有关绑定等各种后果的抱怨。该问题也出现在明显虚假的 KVO 触发中，这完全不足为奇。

处理这个问题的最简单的方法（嗯，最简单的“重新显示保存时的所有内容”之后，我发现这是一个很好的第一遍选项，直到有人抱怨）是监听通用保存通知，然后在每个更新的对象上调用 -changedValues 来选择找出您有兴趣为其触发特定更新的那些。

如果这对您的用例来说效率低下，您可以为您的属性创建自定义访问器（mogenerator 对此有很大帮助），这些访问器收集编辑线程标志以更改您感兴趣的所有属性；并在保存后将其作为通知发送。

举例来说，假设我们有一个专业运动队应用程序，该应用程序会通过在后台解析的 JSON 源不断更新。各种球队、球员、游戏等的所有影响显示的属性。 NSManagedObjects 具有自定义访问器，这些访问器在 {playerStatsChanged, teamStatsChanged, leagueRankingsChanged, yadayadayadaChanged } 的结构中设置标志，对应于当前获取后应用程序中的哪些页面需要重新显示-and-parse 线程完成。然后，一旦保存，它就会使用该标志设置结构发出通用的“更新这些屏幕”通知。无论如何，您可能会将各个更改路径通知合并到某个更高级别的“更新此屏幕”类型逻辑中，对吧？好吧，对于最合理的用例，属性设置器级别几乎是您可以做到的最低开销点。当然对于任何重复获取的更新设计，例如我们的运动队应用程序。