第二章 用户感知与帧率计数器的对应关系
现象识别
用户反馈“滑动不流畅”、“动画掉帧”、“触控延迟”是帧率抖动最直接的主观表现。排查的第一步，是将这些主观感知客观映射到帧率计数器指标上。
判断规则：
- 平均 fps < 45：用户明显感知卡顿。
- 平均 fps > 55 但用户仍反馈卡顿：问题几乎锁定在“帧时间方差”（即跳帧/抖帧）。
- 60fps 下，单帧耗时超过 16ms 就会被感知；90fps 下，阈值缩短为 11ms。
核心概念：用户对卡顿的感知不是线性的。一次 33ms 的单帧跳帧（掉到 30fps）比持续 10 帧的 20ms 帧时间（约 50fps）更容易被识别。这就是帧时间方差的威力。
数据采集
我们需要从系统帧率计数器中采集能够映射用户感知的关键指标。帧时间（FrameCompletedLatency）是连接用户感知与系统状态的桥梁。
| 指标名称 | 数据来源 | 对应感知 |
|---|---|---|
| FramesTotal / FramesDropped | dumpsys gfxinfo | 掉帧率越高，感知越差 |
| FrameCompletedLatency (p99) | Perfetto / gfxinfo HISTOGRAM | 峰值帧时间直接导致卡顿感 |
| Janky frames 占比 | dumpsys gfxinfo | 超过 5% 用户必反馈卡顿 |
# 获取应用的渲染性能数据
adb shell dumpsys gfxinfo <package_name> > gfxinfo.txt
# 关键字段解析
# Total frames rendered: XXX
# Janky frames: XXX (占比超过 5% 即需关注)
# 90th percentile: Xms (反映大部分帧的表现)
# 99th percentile: Xms (反映极端卡顿情况)
原因定位
利用故障树模型，通过帧时间计数器指标逆向定位用户感知异常的根因。
排查陷阱：不要盯着平均帧率看！一个 58fps 但有 5% 跳帧的系统，体验远比 55fps 但稳定无跳帧的系统差。必须关注帧时间分布的尾部延迟。
| 用户感知 | 计数器表现 | 根因排查方向 |
|---|---|---|
| 间歇性卡顿 | 帧时间 >16ms(60fps) 或 >11ms(90fps) 的峰值 | Vsync 信号抖动 / CPU 被抢占 |
| 滑动不跟手 | 帧率在 40-60fps 波动 | 渲染管线阻塞 / GPU 渲染超时 |
| 动画掉帧 | 特定帧的帧时间翻倍（如 33ms） | UI 线程耗时操作 / 布局计算过重 |
修复动作
- 动作 1：调整监控阈值。根据目标帧率（60fps 或 90fps）在监控面板上明确标出 16ms / 11ms 的“红色警戒线”。
- 动作 2：优化帧时间方差。针对跳帧问题，使用 Perfetto 定位耗时具体环节，优先优化 p99 帧时间，而非仅看平均值。
- 动作 3：建立帧时间预算文化。让开发团队明确知晓每一帧的预算上限，避免超时导致跳帧。
复测
验证标准：
- 修复后，在 60fps 下，
maxFrameTime稳定 <16ms，且无连续跳帧。 - 修复后，在 90fps 下，
maxFrameTime稳定 <11ms，且无连续跳帧。
感知测试：组织 10 人盲测，对比修复前后的滑动流畅度。评分提升 >1 分（满分 5 分）视为有效修复。
预防
- 在项目立项阶段定义帧率目标（60fps 或 90fps），并将对应的帧时间预算写入开发规范。
- 在 CI 流程中集成
gfxinfo检测，对Janky frames占比超过 3% 的版本进行拦截。 - 定期进行帧时间方差巡检，在大规模用户反馈前发现并修复潜在的抖动问题。