“运行时间”，“CPU使用率”是文书下的一个有用指标，可以得出任何结论？
已经使用“ 时间分析器 ”和“ CPU监视器 ”在iPhone 4上对应用程序进行了描述，并试图理解它。
如果执行时间是8分钟，CPU“运行时间”大约是2分钟。 大约67％是在主线上，其中52％来自“自己的代码”。
现在，我可以看到大部分时间都在枚举数组（及相关工作），UIKit操作等方面进行了枚举。
问题是，如何从这些数据中得出任何有意义的结论？ 即在这里有什么问题需要修复。
在这个运行时间内，我可以看到很多的CPU负载（中位数为70％），由于应用程序的性质，这是不合理的。
话虽如此，有些事情确实很突出。 在主线程上parsingHTTP响应，急切地创build对象（也由内存分析备份）。
但是，我在这里寻找的只是基于CPU运行时间而得出的有用结论。 即在这里花费“太多”的时间。
更新
让我试着细化一下，以便更好地展示。
根据这个应用程序的function要求，我不明白为什么它不应该能够在iPhone 3G上运行。 CPU平均使用率约为70％，高峰期为97％，仅在iPhone 4上看起来像一面红旗。
对此最明显的反应是调查代码并从中得出结论。
我所希望的是以下forms的绝对答案
- 如果您在CA上花费了25％到50％的时间，那么您的animation有问题
- 如果你在与UIKit相关的任何事情上花费1000毫秒，最好检查你的处理
再说一次，也许在运行时间和CPU使用率方面，没有任何答案只是指示事情正在closures。
回答问题“在这里需要解决的问题是否有问题”很简单：你在使用应用程序时看到问题吗？ 如果是的话（你看animation中的毛刺，或者应用程序挂了一段时间），你可能想要解决它。 如果没有，你可能会寻找过早的优化。
尽pipe如此，在主线程中parsinghttp响应可能是一个坏主意。
在开发的演示文稿中，苹果指出，虽然CPU使用率不是模拟器中的准确指标，但是在设备上进行性能分析时还是需要一些东西。 就个人而言，我会考虑任何线程，没有很好的理由需要大量的CPU时间需要解决的问题。 find时间汇，以百分比为优先级，并开始通过他们的工作。 这些问题现在可能不是什么明显的问题，但是如果他们还没有开始的话，他们会开始降低用户对应用和潜在的设备的体验。
查看他们的文档 ，了解如何有效地使用CPU分析来获取一些便利的提示。
如果枚举数组需要花费很多时间，那么我认为可以使用字典或其他更有效的caching，假设可以省去一些内存来缓解CPU。
一个有效的方法可能是从主线程（ 给定 ）中删除所有的业务逻辑，并在应用程序和parsing/业务逻辑之间build立一个良好的边界层。 从这里你可以更好地勾住一些testing套件，这些testing套件可以更好地告诉你代码是否有问题，或者它只是应用程序UI本身的重要需求。
八分钟？
不用挨打，你想让你的应用程序更快，对吧？
忘记看CPU的负载，并想知道是否是正确的金额。 忘记猜测是否是HTTPparsing。 也许是的，但猜测不会告诉你。 忘记在代码中寻找时机，希望你会发现问题。
你可以直接找出为什么花这么多时间。 这是我使用的方法， 这是一个（业余）video。
这是如果你这样做会发生什么。 首先你会发现一些你永远不会猜到的东西，当你修好它的时候，你会在这8分钟内掉下一大块，比如6分钟。 然后你再做一次，并砍掉另一大块。 你重复，直到你找不到任何要修复的东西，然后它会比你的8分钟快得多。
好的，现在球在你的球场上了。