“运行时间”，“CPU使用率”是否是仪器下的一个有用指标，可以得出任何结论？

Question

使用“Time Profiler”和“CPU Monitor”在iPhone 4上分析了一个应用，并尝试理解它。

鉴于执行时间为8分钟，CPU“运行时间”约为2分钟。 其中大约67％是主线程，其中52％来自“自己的代码”。

现在，我可以看到大部分时间花在枚举数组（和相关工作），UIKit操作等上。

问题是，如何从这些数据中得出任何有意义的结论？即这里有一些错误需要修复。

考虑到应用程序的性质，我可以看到在运行时间（中位数为70％）上的大量CPU负载并非“合理”。

话虽如此，有些事情确实很突出。在主线程上解析HTTP响应，急切地创建对象（也由内存分析备份）。

但是，我在这里寻找的是违规代码以及仅基于CPU运行时间的有用结论。即在这里度过“太多”时间。

更新

让我试着详细说明，以便提供更好的图片。

根据这个应用程序的功能要求，我不明白为什么它不能在iPhone 3G上运行。 CPU使用率中位数约为70％，峰值为97％，只是iPhone 4上的红旗。

对此最明显的回应是调查代码并从中得出结论。

我所希望的是以下形式的明确答案

1. 如果您在CA上花费的时间在25％到50％之间，那么您的动画就会出现问题
2. 如果您在与UIKit相关的任何事情上花费1000毫秒，请更好地检查您的处理

然后，在运行时间和CPU使用情况方面，可能没有任何答案，只有关闭事物的迹象。

Answer 1

回答问题“这里有什么问题需要修复”很简单：你在使用应用程序时是否看到问题？如果是（您在动画中看到故障，或者应用程序暂停一段时间），您可能想要修复它。如果没有，您可能正在寻找过早优化。
尽管如此，解析主线程中的http响应可能是一个坏主意。

Answer 2

在开发演示中，Apple已经指出虽然CPU使用率并不是模拟器中的准确指标，但在设备上进行性能分析时需要保留库存。就个人而言，我会考虑任何占用大量CPU时间的线程，没有充分理由需要解决的问题。 找到时间接收器，按百分比确定优先级，然后开始处理它们。这些可能不是现在可见的问题，但如果它们还没有，它们将开始降低用户对应用程序和可能的设备的体验。

查看their documentation如何有效地使用CPU分析来获得一些方便的提示。

如果数组的枚举花费了很多时间，那么我建议字典或其他更有效的缓存可能是合适的，假设您可以节省一些内存来缓解CPU。

有效的方法可能是从主线程（a given）中删除所有业务逻辑，并在应用程序和解析/业务逻辑之间建立一个良好的边界层。从这里你可以更好地挂钩一些测试套件，可以更好地告诉你代码是否有问题，或者它只是应用程序UI本身的重要要求......

Answer 3

八分钟？

如果没有在丛林中跳动，你想让你的应用更快，对吗？

忘记查看CPU负载并想知道它是否是正确的数量。 忘记猜测它是否是HTTP解析。也许是，但猜测不会告诉你。 忘记在代码计时中翻找东​​西，希望你能找到问题。

您可以直接了解为何花费这么多时间。 Here's the method I use, 和here's an (amateurish) video of it.

如果你这样做会发生什么。 首先，你会找到一些你永远不会猜到的东西，当你修复它时，你会在8分钟内掉落一大块，比如可能长达6分钟。 然后你再做一次，并砍掉另一大块。 你重复，直到你找不到任何要修复的东西，然后它会比你的8分钟更快 。

好的，现在球在你的球场。