KVC 与快速枚举答案

【问题标题】：KVC vs fast enumerationKVC 与快速枚举
【发布时间】：2013-04-26 14:02:34
【问题描述】：

以下哪个更快，为什么？

CGFloat sum = 0;
for (UIView *v in self.subviews)
    sum += v.frame.size.height;

或

CGFloat sum = [[self.subviews valueForKeyPath:@"@sum.frame.size.height"] floatValue];

【问题讨论】：

我怀疑您会注意到少于 100 个子视图的显着差异。对于大型数组，我在这里做了类似的比较：stackoverflow.com/a/15931719/1187415，结果证明快速枚举是最快的。
为什么不自己试试呢？应该很容易调查......我个人会选择更具可读性的解决方案。
@Andrea：快速枚举不会启动多个线程，但您可以将 block enumeration 与 NSEnumerationConcurrent 选项一起使用（也在此处测试：stackoverflow.com/a/15931719/1187415，对不起促销:-)
@MartinR 是的，但是是否建议在主线程之外访问 UI 元素，即使它只是为了获得它们的高度？
这里真的有性能问题吗？如果是这样，您确定这不是架构问题吗？

标签： iphone ios objective-c ipad kvc

【解决方案1】：

首先，您的 KVC 表达式不起作用； KVC 不能用于检索结构成员（除了非常有限的情况，即类具有特殊实现的 valueForKey: 进行特殊处理）。

其次，这听起来像是过早的优化。

您是否真正量化了与此代码相关的性能问题？

否则，您就是在浪费时间“优化”此代码路径。

除此之外，使用 KVC 进行此类操作会给您的代码增加相当大的脆弱性。编译器无法验证传递给 valueForKey: 的表达式，因此，编译时错误或警告现在是运行时错误，只有在执行该代码路径时才会发现。

【讨论】：

编译器无法验证所有KVC表达式。这是否意味着如果我们不能不使用其他东西，我们应该使用 KVC？
一般来说，是的。当然，KVC 有用途，但限制 KVC 的使用、基于内省的编程等...极大地促进了代码库的可维护性。

【解决方案2】：

还可以查看 Apple 文档：

虽然键值编码很高效，但它增加了一层间接性这比直接方法调用稍慢。你应该使用仅当您可以从以下灵活性中受益时才使用键值编码它提供。

Key Value Coding Docs

【讨论】：

【解决方案3】：

真的，一门语言的优雅（或聪明）很大程度上取决于它避免循环的能力。为，而；甚至 快速枚举 表达式也是一种拖累。无论你如何粉饰它们，循环都是一段代码，它执行的操作更容易用自然语言描述。

"求我这个数组中所有员工的平均工资",

double totalSalary = 0.0;
for (Employee *employee in employees) {
  totalSalary += [employee.salary doubleValue];
}
double averageSalary = totalSalary / [employees count];

对比...

幸运的是，Key-Value Coding 为我们提供了一种更简洁（几乎类似于 Ruby）的方式：

[employees valueForKeyPath:@"@avg.salary"];

KVC 集合运算符允许使用 valueForKeyPath: 中的键路径表示法对集合执行操作。

每当您在键路径中看到 @ 时，它表示一个特定的聚合函数，其结果可以返回或链接，就像任何其他键路径一样。

Fast Enumeration 比 KVC 更快。

希望对你有所帮助。

【讨论】：

将 KVC 用于此类任务会在您的代码库中引入脆弱性。具体来说，编译器无法验证 KVC 表达式，因此将潜在错误从在编译时检测到仅在运行时发生该代码路径执行时才会失败。同样，整个第一段都是意见，不会对答案添加任何内容。