iOS CPU 占用率在性能问题中的表现形式-克魔使用教程

在不少性能讨论里，iOS CPU 占用率常被当成一个直观指标：数值高了就是问题，低了就算安全。
但真正参与过线上问题排查之后，会发现这种理解过于粗糙。

我第一次真正被 CPU 占用率困住，并不是因为它“飙到了一个夸张的数”，而是因为——
它看起来不高，却始终维持在一个不该出现的水平。

CPU 问题，往往从一句模糊的反馈开始

那次的反馈很典型：页面不卡，但手机有点热，用一会儿就掉电。

如果只从功能角度看，这几乎没有可操作的信息。
但经验告诉我，这类问题十有八九和 CPU 使用方式有关。

排查 CPU 的第一反应，通常还是 Instruments。

Time Profiler 很快能给出调用栈、线程分布、函数耗时。
在短时间测试里，一切都显得“还行”：

如果就此下结论，很容易认为“CPU 没问题”。

问题出在这里：
这次的 CPU 异常，并不是某一次操作触发的，而是持续存在的状态。

单次 Time Profiler 很难说明：

这类问题，本质上和时间有关。

后来我换了一种方式，不再急着抓调用栈，而是先观察 CPU 在真实使用过程中的变化。

这一步，我用的是 克魔（KeyMob）。

原因并不复杂：
它可以在真机上持续监控 CPU 占用率，并把变化过程完整记录下来，而不是只看某一个采样点。

当我连续使用 App 十几分钟之后，CPU 的问题才真正显现出来：

这些现象，单独看都不算“异常”，
但组合在一起，就很难忽略了。

有了趋势之后，再回到 Instruments，事情就变得简单多了。

我开始刻意盯着几段流程：

最终发现，一个看似无害的轮询逻辑，在页面退出后并没有停止。

如果没有前面的长期观察，这个点很容易被忽略。

在另一个项目中，CPU 占用问题并不来自 Native。

通过 Safari Inspector，我发现某些 WebView 页面在退到后台后，仍然有 JS 定时任务在执行。
每一次执行都不重，但长期叠加，对 CPU 的影响非常稳定。

这类问题，用纯 Native 的 CPU 分析工具很难察觉。

还有一次 CPU 异常，最终是通过 Charles 才理清楚的。

抓包发现：

单次看，这些行为都算不上严重。
但在真实使用中，它们共同维持了一个不必要的 CPU 活跃状态。

经历这些排查之后，我对 CPU 占用率的理解发生了变化：

在工程实践中，我更关心的是：

KeyMob 在这里的价值，并不是替代 Instruments，而是帮我找到该用 Instruments 看哪里。

现在在处理 CPU 相关问题时，我通常会这样配合工具：

这样做的好处是，不会被单一视角误导。