帧率基础知识：什么是帧率、掉帧、卡顿衡量指标
做性能优化这么些年，我越来越觉得帧率就是流畅度的"体温计"。你想想看，用户感受到的卡顿，本质上都是帧率在"报警"。这一章我们就来拆解帧率的基础概念，以及怎么用指标把"卡顿"这件事量化清楚。
1. 帧率 (FPS) —— 流畅度的"心跳"
帧率，全称 Frames Per Second，简称 FPS。说白了就是手机屏幕每秒能画出多少张画面。60 FPS 就是每秒 60 张，120 FPS 就是每秒 120 张。数字越大，人眼感觉越丝滑。
我记得刚入行时觉得 30 FPS 也挺好啊，何必非要跑 60？后来自己刷微博，快速滑动列表时发现文字全是糊的，眼睛一会儿就酸了。从那以后我对帧率就特别敏感——低于 60 的流畅度，说白了就是"能忍但难受"。
关键认知：人眼对 60 FPS 以上的变化不太敏感，但对 60 FPS 以下的抖动极其敏感。卡顿感往往来自"该 60 的时候掉到了 30"，而不是一直 30。稳定的低帧率反而比忽高忽低的帧率更容易适应。
2. 掉帧 —— 流畅度的"断点"
掉帧，英文叫 Jank 或 Frame Drop。指的是某一帧本该在 16.6ms（60FPS 下的帧间隔）内渲染完成，结果超时了。超时的那一帧就被"丢掉"了，画面会出现一次跳跃或停滞。为什么会这样？
原因很多：主线程耗时操作、布局过度绘制、GC 频繁触发、WorkManager 任务抢占资源……嗯，这些我们后面章节会一个个拆解。但本质就一句话——该干活的时间段里，没干完活。
个人经验：我排查掉帧问题有个习惯——先看是不是"周期性掉帧"。每隔几秒掉一帧，大概率是后台任务或 GC 导致的。随机掉帧就得看具体操作路径了，多半是布局或动画的问题。
避坑指南：我曾经遇到一个案例，掉帧率只有 2%，但用户反馈卡顿很严重。后来发现是帧间隔不均匀——虽然整体掉帧不多，但连续好几帧都接近 16ms 极限，稍微一波动就超。光看掉帧率是不够的，还得看帧间隔的分布。
3. 卡顿衡量指标 —— 把"感觉"变成数字
做优化不能只靠"感觉卡"或"感觉不卡"，得有量化指标。下面这几个是我在项目中常用的，也是业界通用的标准。
| 指标 | 含义 | 阈值 | 说明 |
|---|---|---|---|
| FPS | 每秒帧数 | ≥ 60 为佳 | 最直观，但只看平均值容易被骗 |
| Jank | 掉帧次数 | 每 1000 帧中 ≤ 5 次 | 单帧渲染超过 16.6ms 即算一次 |
| Big Jank | 严重掉帧次数 | 每 1000 帧中 ≤ 1 次 | 单帧渲染超过 50ms |
| Freeze | 冻屏次数 | 每 1000 帧中 0 次 | 单帧渲染超过 700ms，用户能明显感知"卡死" |
| Frame Time | 帧渲染耗时 | P95 ≤ 16ms | 看百分位分布，比平均值更有参考价值 |
| Jitter | 帧间隔抖动 | 标准差 ≤ 3ms | 衡量帧率的稳定程度 |
这些指标各有侧重。我个人习惯先看 FPS 和 Jank 率，快速定位问题；然后用 Big Jank 和 Freeze 判断严重程度；最后用 Frame Time 的百分位分布来深挖根因。嗯，这套流程在 WorkManager 冲突场景下特别管用。
4. 帧率与垂直同步（V-Sync）
垂直同步，也就是 V-Sync，是用来防止画面撕裂的机制。它让渲染引擎等屏幕刷新信号来了再提交帧，保证帧与帧之间完整对齐。但 V-Sync 有个副作用：如果渲染耗时刚好卡在 16ms 左右，就会频繁出现"刚好超时一点"的情况，导致帧率在 30 FPS 和 60 FPS 之间反复横跳。
这就是所谓的帧率抖动。WorkManager 调度冲突导致的帧率抖动，本质上就是这个机制在作祟——后台任务突然抢占 CPU/IO，导致渲染线程来不及在 V-Sync 周期内完成工作。
核心观点：帧率抖动比稳定的低帧率更影响用户体验。稳定的 30 FPS 用户能适应，但忽高忽低的 30-60 FPS 会让用户明显感觉到"一卡一卡"的。掉帧不可怕，忽快忽慢才要命。
5. 知识体系一览
下面这张图总结了帧率、掉帧和卡顿衡量指标之间的关系。我建议你保存下来，以后排查问题时可以对照着看。
从图中你能看出，帧率是基础，掉帧是现象，指标是工具。三者环环相扣。工作中遇到卡顿问题，我的排查路径通常是：先看 FPS 趋势 → 定位掉帧点 → 用指标量化严重程度 → 分析 Frame Time 分布 → 找到根因。这套流程在 WorkManager 场景下同样适用，后面我们会结合具体案例一步步走一遍。