在日常测试或调试中，CPU 使用率几乎是最容易被提到、却也最容易被误解的指标。
有人看到 CPU 一度飙高就紧张，也有人在卡顿出现时却发现 CPU 看起来“还好”。

真正有价值的不是某个瞬时百分比，而是在什么操作下、哪个进程、持续了多久。

下面结合一次相对完整的实践过程，聊聊我是怎么在 iOS 设备上把 CPU 使用率这件事看清楚的。

为什么不能只看 Xcode 里的 CPU

如果你在 Mac 上开发，Xcode 的 Debug Navigator 或 Instruments 已经足够强大。但在这些场景下，它会有明显局限：

  • 测试包或非开发签名的 App 无法直接 attach
  • 真机长时间运行不方便持续盯着
  • 多 App 场景下对比不直观

所以在一些性能回归测试、问题复现阶段，我更倾向于多工具并行，而不是“只盯一个窗口”。

一个常见场景：滑动不顺，但 CPU 看不出异常

有一次测试中，App 的列表滑动有明显掉帧，但用 Xcode 看 CPU，单个时刻并不高。

问题出在两个细节上：

  • CPU 峰值很短，容易被忽略
  • 系统总 CPU 和 App CPU 之间没有对照

这类问题如果只看某一个点，基本判断不出来。

把 CPU 放到过程里看

在这类场景下，我会先做一件简单但关键的事：
让 CPU 数据连续记录下来，并和实际操作对齐。

设备与工具准备

  • 一台真实 iPhone / iPad
  • USB 或 Wi-Fi 连接
  • 关闭无关后台应用

同时打开两个工具：

  • Xcode（必要时用来深入定位）
  • 克魔（KeyMob），负责持续监控

用克魔看 iOS CPU 使用率的实际操作

进入性能监控

  1. 启动克魔，连接设备
  2. 左侧选择【性能图表】
  3. 在指标选择中勾选 CPU
  4. 同时保留系统总 CPU

这样做的目的，是避免只看单个 App 而忽略系统负载。
性能监控

选择要观察的进程

点击“选择 App”后：

  • 勾选目标 App
  • 同时保留“系统总 CPU”
  • 如果是多任务场景，可以额外选一个对照 App

这里我一般不超过 3 个进程，避免图表失去可读性。

开始监控并触发操作

点击开始后，不急着分析，先完整走一遍真实使用路径：

  • 打开页面
  • 快速滑动
  • 切换 Tab
  • 返回、再次进入

克魔会把这些过程完整记录下来，CPU 曲线会自然反映每个动作的成本。

怎么理解看到的 CPU 数值

在 iOS 上，CPU 使用率经常会超过 100%，这是正常现象。

原因很简单：

  • iPhone 使用多核 CPU
  • 显示的是所有核心的使用总和

举个容易理解的例子：

  • 6 核设备
  • 某 App 显示 180%
  • 实际是平均占用了接近 2 个核心

真正需要警惕的不是“高”，而是：

  • 是否持续
  • 是否和操作强相关
  • 是否与系统总 CPU 同步抬升

把 CPU 和其他工具结合起来

和日志对齐

当看到 CPU 明显抬升时，我会同步打开克魔的【实时日志】：

  • 过滤当前 App
  • 关注是否有重复调用、异常输出

有时 CPU 高并不是算法问题，而是某个逻辑被反复触发。
实时日志

和 Instruments 配合

当确认某个操作段 CPU 异常稳定复现后，再回到 Xcode：

  • 用 Time Profiler 定位方法级耗时
  • 缩小分析范围，而不是全局扫

这一步如果一开始就做，成本反而更高。

一点实践中的判断经验

在多次项目里，我逐渐形成了一个简单判断标准：

  • 短促的 CPU 峰值，大多是合理行为
  • 持续抬高且无法回落，才值得追
  • 系统总 CPU 同时升高，要考虑外部因素