为什么需要帧率监控
我做性能优化有些年头了。有个问题经常被新人问：“帧率监控不就是看FPS吗？低就优化，高就收工，有什么好讲的？”
嗯，你要是也这么想，那大概率踩过不少坑。
帧率监控远不止看一个数字。它是你定位卡顿、诊断后台调度问题的眼睛。今天我就跟你聊聊，为什么必须把帧率监控当成一门基本功。
用户不关心你干了什么，只关心画面爽不爽
说个真实案例。2019年我做一个直播弹幕项目，测试时帧率稳定60，但是用户反馈“刷弹幕时手机发热，滑动卡顿”。我一看帧率曲线——大部分时间满帧，可每过十几秒就掉到40以下，持续一秒左右。
这一秒的卡顿，用户感知非常明显。
人的视觉系统对帧率抖动比平均帧率更敏感。你平均帧率60，但只要出现几次掉到30的瞬间，用户就觉得“这App好卡”。
关键指标：
- 平均帧率（Avg FPS）—— 及格线
- 帧率方差 / 标准差 —— 稳定性
- 掉帧次数（Jank Count）—— 用户体验直接关联
- 最大帧耗时（Max Frame Time）—— 临界点
所以我习惯把帧率曲线画出来看。光看平均值容易误判。你想想看，一个App平均59.8帧，但每3秒就卡0.5秒，用户早就摔手机了。
后台调度是卡顿的头号元凶
很多帧率问题不是App本身逻辑有多重，而是后台线程调度不当导致的。
我曾经优化一个短视频应用，发现滑动列表时帧率突然掉到20左右，持续一两秒。查堆栈，发现主线程卡在加锁等待上。但锁在哪？—— 一个后台线程在批量处理图片下载，长时间持有锁，主线程渲染时只能等。
这就是典型的后台调度问题：
- 优先级翻转：低优先级后台线程占了锁，高优先级主线程等锁。
- CPU峰值：后台任务突然爆CPU，导致渲染线程得不到时间片。
- GC/内存抖动：大量对象分配触发垃圾回收，全局停顿。
- I/O阻塞：后台读写文件或网络，导致内核态切换过多。
我曾经踩过的坑：
有一个版本上线后，部分用户反馈进游戏关卡时卡5秒。查了半天，发现是因为后台定时器每100ms执行一次日志写入，正好和帧率峰值重叠。修复后帧率瞬间稳定。 —— 很多卡顿，根本不是主线程代码的问题。
帧率监控帮你把“玄学”变成“科学”
没有监控，你只能靠猜：“感觉有点卡，是不是网络波动？” 有监控，你就能看到精确的帧时间分布、掉帧模式、关联的CPU/线程状态。
我个人习惯把这些需要监控的点分成三个层次：
| 层次 | 重点关注 | 工具目标 |
|---|---|---|
| 指标层 | 平均帧率、帧率曲线、掉帧次数 | 快速判断是否卡顿 |
| 系统层 | CPU/GPU使用率、线程状态、锁等待 | 定位后台调度问题 |
| 代码层 | 函数耗时、内存分配、I/O操作 | 精准修复瓶颈 |
你看，如果你只有指标层的数据，你只能知道“卡了”，但不知道为什么卡。加上系统层和代码层，你才能动手修。
说白了，帧率监控就是给你一个可量化的入口，让你从模糊的“卡”变成：
- “帧时间在200ms时，CPU主频降至最低”
- “掉帧前1秒，后台线程B开始大量写文件”
- “堆内存水位超过80%时，触发GC导致暂停”
这样的数据，才能指导优化方向。
没有监控，你怎么量化优化效果？
我曾经遇到过团队里一位同学拍着胸脯说“我优化了列表渲染，肯定不卡了”。结果上线后用户反馈依然卡。为什么？因为没有基线数据。
你优化前帧率是多少？掉帧多少次？优化后这些数字变了没有？如果没有监控，你永远无法证明优化是有效的。
小建议：
每个版本上线前，先在测试环境下跑一遍帧率基线。用adb shell dumpsys gfxinfo（安卓）或 Instruments（iOS）导出帧时间数据。然后持续跟踪。我一般在CI流程里加一个帧率检测步骤，掉帧超过阈值直接告警。
本章核心逻辑
下面这张图帮你理清我们为什么需要帧率监控：
小结：帧率监控的三大价值
- 量化用户体验：把“卡”变成可测量的掉帧率、帧时间分位数。
- 定位后台调度问题：结合线程状态、锁等待、CPU占用来揪出元凶。
- 验证优化效果：用数据说话，而不是“我觉得不卡了”。