测量CPU使用率，在Xcode中呈现UIView

Posted 2021-03-27

我在Interface Builder中有一个nib的视图。它在笔尖内有几个UIStackViews，我使用它因为它很容易对齐UI元素。一位同事建议我不要使用UIStackViews，因为从计算的角度来看它们“昂贵”。另一种方法是手动设置各个元素的约束。

我可以使用什么Xcode工具来验证我的同事的断言以及如何使用它？我发现的最好的东西是this，但我希望能有更多粒度的东西。有问题的笔尖是UITableViewCell。

答案

从计算的角度看，它们“昂贵”

好的，我现在将尝试证明这完全是假的。

堆栈视图不是魔术。堆栈视图不执行任何特殊的运行时调整。堆栈视图只是一个约束制造者，不多也不少。你也是。堆栈视图所做的一切都可以做到。并且堆栈视图的结果约束与您自己创建的约束完全相同（假设您甚至知道如何）。因此，限制本身并不仅仅因为堆栈视图使它们成本更高。

那么让我们谈谈约束的初始生成。好吧，堆栈视图通过死记硬背生成约束。它只是一个简单的公式化方法，基于已经由堆栈视图的设置和（在某些情况下）排列的子视图的内在内容大小等已经给出的参数。因此，堆栈视图实际上没有时间吐出它生成的约束，并且它只需要执行一次。

因此，如果约束的产生并不昂贵，并且如果约束本身并不昂贵，那么费用在哪里？它无处可去。

有人可能会争辩说，对于特定的期望结果，使用堆栈视图是不必要的复杂或懒惰，因此自己制定约束会“更好”;但“昂贵的”在我看来并不是一个可以反对堆栈视图的真正指控。

另一答案

在挖掘中，我找到了一个名为LayoutFrameworkBenchmark的回购。我在iPhone 7+模拟器上运行Xcode 12中的基准测试。我收集了数据并将其转储到Google表格中。它确实表明UIStackView是pokey与其他布局方法。

我现在明白为什么两个阵营中似乎都有人，但在现实世界中，人眼不太可能注意到差异，除非它是一个巨大的收藏.