1. 现象识别：帧率回归的典型表现与感知阈值
帧率回归排查的第一步，是准确判断“卡了”到底是真的性能恶化，还是心理错觉。AOSP版本更新后，渲染流水线的任何一环（App主线程、RenderThread、SurfaceFlinger、HWC合成）都可能引入回归，表现出的掉帧特征各不相同。本章的目标是：建立一套从“用户感知”到“掉帧特征”的量化归类方法，让后续数据采集有明确的方向。
1.1 典型卡顿场景
以下场景是版本回归后最容易暴露卡顿的“高敏感区”，排查时应当优先复现：
| 场景 | 典型触发动作 | 回归敏感度 | 主要原因方向 |
|---|---|---|---|
| 列表快速滑动 | 垂直快速翻页（50dp/s 以上） | 极高 | RV复用逻辑、Layout异步化、ItemDecoration |
| 应用冷/热启动 | 点击图标到首帧显示 | 高 | ViewRootImpl初始化、Surface创建、缓冲队列 |
| 多窗口分屏切换 | 拖拽分隔条或旋转屏幕 | 中 | WMS配置变更、ActivityRelaunch、尺寸缓存 |
| 连续动画过渡 | 页面转场、返回手势、对话框弹出 | 高 | AnimationFrameCallback、同步屏障机制 |
| 输入低延迟场景 | 触控绘制、笔输入 | 高 | Choreographer帧回调、InputDispatcher时序 |
排查建议：高频滑动列表是“识别回归”的最快路径。如果版本更新后用户普遍反馈刷信息流时“一卡一卡”，优先检查
Choreographer.doFrame 的 DRAW_SYNC 阶段耗时。
1.2 掉帧特征分层
一次完整的丢帧流程，在 Systrace / Perfetto 上呈现出三层可量化特征。我们将这些特征整理为 FPS 故障树：
掉帧特征故障树（非叶子节点为中间原因，叶子节点为直接量化指标）
├─ 帧到达不连续 → 相邻帧间隔 ≥ 30ms
├─ 同步屏障超时 → Barrier -> doFrame 延迟 > 16.6ms
├─ 冗长帧绘制 → 单帧 SurfaceFlinger 合成耗时 > 8ms
└─ 缓冲队列积压 → dequeueBuffer 阻塞 > 15ms
├─ 帧到达不连续 → 相邻帧间隔 ≥ 30ms
├─ 同步屏障超时 → Barrier -> doFrame 延迟 > 16.6ms
├─ 冗长帧绘制 → 单帧 SurfaceFlinger 合成耗时 > 8ms
└─ 缓冲队列积压 → dequeueBuffer 阻塞 > 15ms
更具体的，各层掉帧对应的 Perfetto 指标 如下表：
| 层级 | 掉帧类型 | 关键信号（在 trace 中查找） | 典型阈值 |
|---|---|---|---|
| Layer 1 | App 输入-绘制-提交 | Choreographer#doFrame + input event dispatch |
doFrame > 16ms 即为异常 |
| Layer 2 | SF 合成 | CompositionEngine::composeFrame + HWC presentDisplay |
合成周期 > 8ms 产生连续掉帧 |
| Layer 3 | 显示硬件 | VSYNC / GPU completion |
帧间距 > 16.6ms 超过 3 次即“明显卡顿” |
1.3 用户感知阈值
并非所有掉帧都会触发用户抱怨。实验数据表明，用户对卡顿的感知存在 “可接受窗口”：
- 单帧丢帧 < 3 次/15秒：感知极低，典型用户不抱怨。
- 连续丢帧 3~5 次/15秒：部分用户反馈“有点慢”，但不稳定。
- 连续丢帧 > 5 次/15秒 或 单次掉帧 > 50ms：明显卡顿，70% 以上用户可感知。
避坑：有些回归只在特定场景累积出现，比如“每次切换App后前10帧都掉帧”——这类微卡顿很难被粗略的“平均帧率”捕捉。务必使用 帧间距 CDF（累积分布） 而非均值来判断回归。
1.4 快速判断规则
当收到帧率回归报告时，按以下顺序快速归类：
- 看帧间隔分布：用
adb shell dumpsys gfxinfo导历史帧数据，抓最后 120 帧。 - 筛选异常帧：间隔 > vsync period × 1.5（即 25ms）的帧标记为掉帧。
- 找聚集模式：掉帧是否集中在某个 Activity / SurfaceView / App 冷启动阶段。
- 比对旧版本：相同场景下，新版本掉帧次数 / 间隔峰值是否超过 20% ——超过即为回归。
命令行示例：
统计后，将帧间隔 > 25ms 的帧编号列出来，即为“掉帧候选列表”。
# 获取最近 128 帧的绘制时间（毫秒）
adb shell dumpsys gfxinfo com.example.app framestats | grep -A 128 "Draw_time统计后，将帧间隔 > 25ms 的帧编号列出来，即为“掉帧候选列表”。
1.5 本章节核心流程图
下面这张 掉帧现象识别决策图 将帮助你从用户反馈的描述快速映射到需要采集的数据类型：
本章要点小结：
· 帧率回归首先从“用户反馈场景”切入，而不是直接看 FPS 数字。
· 掉帧特征分为“单次大丢帧 / 连续长帧 / 帧间隔抖动”三类，分别指向不同的底层链条。
· 用户感知阈值：连续掉帧 5+ 次 / 15s 或单次 > 50ms 为明显回归。
· 快速排查命令：
· 帧率回归首先从“用户反馈场景”切入，而不是直接看 FPS 数字。
· 掉帧特征分为“单次大丢帧 / 连续长帧 / 帧间隔抖动”三类，分别指向不同的底层链条。
· 用户感知阈值：连续掉帧 5+ 次 / 15s 或单次 > 50ms 为明显回归。
· 快速排查命令：
adb shell dumpsys gfxinfo 获取帧间隔原始数据。