什么是资源密集度较低的：绑定、KVO 或通知
而不是尝试运行一堆测试。有人知道什么是资源消耗较少的吗？
绑定、KVO 还是通知？有没有人也测试过看看？
Rather than trying to run a bunch of tests. Does anybody know what is less resource intensive?
Bindings, KVO, or Notifications? Has anyone tested to see as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就通知与 KVO 而言，Chuck 的答案是非常正确的，但我想扩展他提到的“绑定是 KVO + KVC + ...”部分，因为这才是真正的痛苦所在在屁股上也可以。键值编码似乎是这里更重要的考虑因素，因为没有它就无法使用绑定。如果您有充分的理由担心性能，那么您最好注意大量使用 KVC 可能产生的成本。
我想说的是，任何因单个操作而需要大量查询的情况（例如：向数千个对象询问每个多个关键路径的结果）都将表明您可能希望避免 KVC（以及通过以下方式进行的绑定）：扩大）。 尤其具有长键路径（ -valueForKeyPath: 与 -valueForKey: ）。
我自己就遇到了这个问题，现在正在努力消除我的架构的这一部分。当您通过按下按钮（即使使用 NSOperation/Queue）向 16,000 个对象询问六个长键路径的结果时，键值编码相对较小的成本可能会严重增加。使用 KVC 和老式的 [[object message] message...] 调用之间的区别可能意味着在大型作业中几秒钟到一两分钟以上的区别。对我来说，直接调用访问器的相同查询（如 [参数名称] 或 [[参数变量] 名称]）代表速度大约提高了 500%。诚然，我的数据模型相当复杂，典型文档包含大量数据。
另一方面，如果您的应用程序的许多单个操作影响/查询一个或几个对象，并且大多是面向键值观察的（即更改姓氏并立即在几个视图中更新），那么它的简单性可以类似于魔法。
总之：如果您的应用查询/更新大量数据，您可能会更好地避免查询/更新部分的 KVC 和绑定，因为 KVC，而不是 KVO >。
Chuck's answer is quite right as far as notifications vs. KVO goes, but I'd like to expand on the "Bindings are KVO + KVC + ..." part he mentioned because that's where the real pain in the ass can be. Key Value Coding seems like it's the more important consideration here, since you can't use Bindings without it. If you're worrying about performance for good reasons, you'd do well to note the cost heavy use of KVC can incur.
I would say that any circumstances that call for heavy querying as a result of a single action (example: asking a few thousand objects for the results of multiple key paths each) would be an indicator that you might want to avoid KVC (and Bindings by extension). Especially with long key paths ( -valueForKeyPath: vs. -valueForKey: ).
I've run hard up against this myself and am now working to eliminate this part of my architecture as a result. The relatively minute cost of Key Value Coding can seriously add up when you're asking 16,000 objects for the result of half a dozen long key paths as a result of a button press (even with NSOperation/Queue). The difference between using KVC and good-old-fashioned [[object message] message...] calls can mean the difference between a few seconds and well over a minute or two on large jobs. For me, the very same query calling the accessors directly (like [parameter name] or [[parameter variable] name]) represented roughly a 500% increase in speed. Granted, mine is quite a complex data model with a large volume of data for a typical document.
On the other hand, if many of your app's single actions affect/query one or a handful of objects and are mostly Key Value Observing-oriented (ie, change a last name and have it update in a few views at once), its simplicity can be akin to magic.
In summary: if your app queries/updates large volumes of data, you might do better to avoid KVC and Bindings for the query/update part because of KVC, not because of KVO.
在 OS X 上，这通常并不重要。它们都很轻。苹果本身就依赖它，因此实现是高度优化的。我会编写代码，使其尽可能具有可读性，并且仅在必要时优化速度/资源消耗。
另一点是苹果经常改变操作系统版本的实现。因此，各种特定技术的相对成本（速度、资源消耗等）经常发生变化。在网上找到的内容通常可能已经过时。苹果本身就强调永远不要假设哪个更快、更轻，而是要自己使用profiler（Instruments等）来衡量瓶颈。
On OS X, it doesn't generally matter. They're all lightweight. Apple itself relies on it, and so the implementations are highly optimized. I would write the code so that it is as readable as possible, and only optimize the speed/resource consumption when it's necessary.
Another point is that Apple often changes the implementation across the OS version. So, the relative cost (speed, resource consumption etc.) of various particular technologies often change. What can be found on the 'net can be often outdated. Apple itself emphasizes never to assume which is faster and lighter, and instead to use profiler (Instruments, etc.) to measure the bottleneck yourself.
这些本身并不是真正不同的选择。 KVO 是通知的一个特例。绑定是 KVO + KVC + 几个粘合类。
These aren't really distinct options, per se. KVO is a special case of notifications. Bindings are KVO + KVC + a couple of glue classes.