什么是资源密集型：绑定，KVO或通知

Question

而不是尝试运行一堆测试。有人知道资源密集程度较低吗？

绑定，KVO或通知？有人测试过吗？

Answer 1

在OS X上，它通常并不重要。它们都很轻巧。 Apple本身依赖它，因此实现得到了高度优化。我会编写代码，使其尽可能可读，并且只在必要时优化速度/资源消耗。

另一点是Apple经常改变OS版本的实现。因此，各种特定技术的相对成本（速度，资源消耗等）经常改变。在网上可以找到什么可以经常过时。 Apple本身强调永远不要假设哪个更快更轻，而是使用分析器（仪器等）来自己测量瓶颈。

Answer 2

就通知与KVO而言，Chuck的答案是完全正确的，但我想扩展他所提到的“绑定是KVO + KVC + ......”部分，因为那是在哪里屁股真正的痛苦可以。关键值编码似乎是这里更重要的考虑因素，因为没有它就不能使用Bindings。如果你出于好的理由担心性能问题，那么你应该注意KVC的大量使用会带来成本。

我会说任何因单个动作而需要进行大量查询的情况（例如：向几千个对象询问每个多个关键路径的结果）将表明您可能想要避免KVC（和扩展的绑定）。 特别是，具有长键路径（-valueForKeyPath：vs. -valueForKey :)。

我自己也在努力克服这个问题，现在正努力消除我的架构中的这一部分。当您按下按钮时（即使使用NSOperation / Queue）要求16,000个对象获得六个长键路径的结果时，键值编码的相对微小的成本会严重累加。使用KVC和老式[[对象消息]消息...]调用之间的区别可能意味着在大型作业上几秒钟到一两分钟之间的差异。对我来说，直接调用访问器的相同查询（如[参数名称]或[[参数变量]名称]）大约表示速度增加了500％。当然，我的是一个非常复杂的数据模型，其中包含大量典型文档的数据。

另一方面，如果您的应用程序的许多单个操作影响/查询一个或少数几个对象，并且主要是面向键值观察（即更改姓氏并在一些视图中同时更新） ，它的简洁可以类似于魔术。

总结：如果您的应用查询/更新大量数据，由于 KVC ，您可能最好避免查询/更新部分的KVC和绑定，而不是因为 KVO

Answer 3

本身并不是真正不同的选择。 KVO是一个特殊的通知案例。绑定是KVO + KVC +几个胶水类。