iOS卡顿监控落地
为什么需要“可量化卡顿”
用户反馈“App 很卡”通常不具备可定位信息。需要把主观体验转成客观指标，才能进入工程闭环。
指标体系
建议至少落地三类指标：
- 帧率类：FPS、掉帧次数。
- 主线程阻塞类：单次阻塞时长、阻塞频次。
- 场景类：页面维度卡顿分布（首页、详情页、下单页）。
监控方案
RunLoop 监控主线程阻塞
在主线程 RunLoop 进入关键状态后，如果超过阈值（如 200ms）未切换，可判定一次卡顿。
关键点：
- 采样频率不要太高，控制性能开销。
- 只上报超过阈值的事件。
CADisplayLink 统计掉帧
通过渲染回调计算帧间隔，估算短窗口 FPS。适合评估动画与滑动流畅度。
堆栈采集
发生卡顿时抓主线程堆栈，用于后续聚合定位热点调用链。
上报与聚合
上报字段建议包含：
- app 版本、设备型号、系统版本
- 页面标识、网络类型
- 卡顿时长、发生时间
- 主线程堆栈签名
服务端聚合时按“堆栈签名 + 页面 + 版本”聚类，快速找到 TOP 问题。
治理路径
UI 层
- 避免主线程大图解码
- 避免复杂 AutoLayout 频繁重算
- 列表滚动中减少同步 IO
业务层
- 拆分大任务，分批执行
- 网络回调中重逻辑移到后台线程
- 缓存预热放在页面空闲阶段
工程层
- 设定性能门禁：核心页面卡顿率超阈值禁止发版
- 将卡顿指标接入看板与报警
常见误区
- 只看平均 FPS，不看长尾卡顿
- 卡顿时不抓堆栈，导致无法定位
- 监控太重，反向影响性能
总结
卡顿治理不是一次性优化，而是“监控-定位-修复-回归”的持续工程。先把数据采集标准化，优化效率会明显提高。