在日常测试或调试中，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 使用率的实际操作
进入性能监控
- 启动克魔，连接设备
- 左侧选择【性能图表】
- 在指标选择中勾选 CPU
- 同时保留系统总 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 同时升高，要考虑外部因素