帧率抖动现象定义与影响
做性能优化的这些年，我见过太多产品在帧率上栽跟头。界面卡一阵、顺一阵，用户骂得比直接卡死还难听。你想想看，一个 App 要是每秒 60 帧流畅跑着，突然掉到 30 帧，又瞬间弹回去，那种「忽快忽慢」的感觉，其实就是帧率抖动。
什么是帧率抖动
帧率抖动，说白了就是每帧的渲染时间不稳定。正常渲染一帧需要 16.7ms（60fps），但有的帧花了 30ms，有的只花 5ms。这种时间上的波动，反映在屏幕上就是视觉上的「突跳」或「微卡」。
我记得有一次调试一个视频播放器，播放列表滑动时总有一阵一阵的迟滞感。用 Systrace 抓了一圈，发现帧率在 40fps 到 55fps 之间来回弹，从来没稳住过。这就是典型的帧率抖动。
| 场景 | 平均帧率 | 帧间隔方差 | 体验评价 |
|---|---|---|---|
| 理想状态 | 60 fps | < 2 ms² | 流畅平滑 |
| 轻微抖动 | 55 fps | 5–10 ms² | 偶有跳帧感 |
| 严重抖动 | 45 fps | > 20 ms² | 明显卡顿，不可接受 |
为什么用户对抖动比持续低帧更敏感？我个人的理解是：人眼习惯了匀速运动，一旦节奏被打乱，大脑就会判断为「异常」，触发负面情绪。低频持续的卡顿反而容易被适应——说白了，神经没被突然刺激到。
帧率抖动对用户体验的伤害
伤害不是一点点，是多维度的。我用一个真实的案例来说吧。
曾经有一个电商 App，首页商品列表在快速滑动时偶尔出现「微闪屏」。测试同学报 bug 时描述得挺轻：「滑动时列表有点晃眼」。但上线后用户投诉率直接飙升了 3 倍，尤其是 iOS 设备。后来排查出来，是一个后台日志压缩任务每次触发都吃掉 20ms 的 CPU 时间，正好卡在 ScrollView 动画帧上。
你看看，抖动直接导致：
- 视觉疲劳：眼睛需要反复对焦，容易酸胀
- 操作误判：点击时刚好抖了一下，点错位置
- 信任崩塌：用户觉得 App 不稳定，以后不想再用
为什么后台任务常是元凶
你可能会问：明明前台 UI 线程在跑，后台任务怎么影响到它？
我刚开始做系统调试时也犯过迷糊。后来用 perf 看了 CPU 调度才发现，现代操作系统的线程调度是按时间片轮转的。后台线程在做压缩、解码、网络上传这些高计算量任务时，会抢占 CPU。如果调度器把时间片切给了后台线程，UI 线程的渲染就被迫延后。
说白了，后台任务和前台渲染线程在同一个 CPU 核上打架。谁赢了，谁就占着时间片。渲染线程一旦拿不到足够的时间，帧渲染就会超时。
- CPU 时间片被抢：后台任务优先级高或占用时间长，挤占渲染线程
- 渲染线程饥饿：连续几帧的渲染间隔被动拉长，产生抖动
- 同步阻塞：后台任务持有锁，渲染线程等锁释放，直接拖慢
知识体系一览
我把这一章的核心逻辑画了一张图，你一看就明白。