帧率与卡顿
平均帧率达到 60 不代表画面流畅。一段平均 58 帧的采集中，可能每秒都有掉帧，而用户每次都能感觉到。
iOS 按固定间隔刷新画面：60 Hz 屏幕为 16.7 毫秒，120 Hz ProMotion 屏幕为 8.3 毫秒。如果一帧的工作没有在间隔内完成，这一帧就会被丢弃。帧率指标报告的是每秒实际呈现的帧数。
因此，120 Hz 设备稳定在 60 帧并不代表有问题，这是 ProMotion 在显示静态内容时自动降低刷新率的正常表现。真正需要关注的是用户拖动时帧率从 120 降到 40。
关注帧率下降，而非平均值
Section titled “关注帧率下降，而非平均值”在克魔助手的采集结果中，请按以下顺序分析：
- 找到帧率下降的位置。 即曲线快速下降后又回升的地方。
- 确认发生的时机。 例如启动时、首次滑动时或每次加载图片时。
- 查看同一时刻的其他曲线。 原因通常可以在这一步确定。
| 帧率下降时的表现 | 可能原因 |
|---|---|
| CPU 升高 | 主线程负载过重，例如布局、JSON 解析、图片解码、同步读文件 |
| GPU 升高、CPU 平稳 | 渲染瓶颈，例如过度绘制、模糊、阴影、离屏渲染、视图层级过深 |
| 内存骤增 | 单次大量内存分配，常见于为显示缩略图而解码整张原图 |
| 网络有流量 | 在错误的线程上等待网络请求 |
| 各项指标均无变化 | 阻塞发生在 App 进程之外，或设备正在降频 |
优先排查的问题
Section titled “优先排查的问题”- 在主线程解码图片。 将 4000 像素的图片显示在 200 像素的 cell 中时，整张图片都会被解码。请在显示前先降采样。
- cell 未被复用。 列表在重新创建视图而非复用视图时，CPU 占用会随滑动速度线性增长。
- 模糊和阴影。 二者在电脑 GPU 上开销很小，在手机上开销较大。为运动中的带阴影视图指定明确的 shadowPath。
- 滑动回调中的同步操作。 拖动过程中访问磁盘或网络，必然会导致卡顿。
- 深层级视图中的 Auto Layout。 约束求解的开销增长速度快于视图数量。
准确测量的方法
Section titled “准确测量的方法”- 使用支持的最旧机型。 帧时间预算固定为 16.7 毫秒，性能较强的芯片会掩盖代码问题，旧机型则不会。
- 等设备降温后再测。 降频导致的卡顿无法通过修改代码解决。
- 每次重复同一段操作。 使用同一个列表，保持相同的滑动距离和速度。
- 使用数据线连接采集。 无线采样本身存在抖动，无法与要测量的卡顿区分。
帧率之外的卡顿
Section titled “帧率之外的卡顿”部分卡顿不会体现在帧率上，例如点击后 300 毫秒才响应、动画延迟启动。请查看该操作前后的 CPU 曲线和实时日志。如果拖动过程中日志输出出现长时间空白，这通常是最直接的证据。