📚 课程目录第3章确定抖动发生在哪一帧

3. 确定抖动发生在哪一帧：FrameCallback分析、Choreographer回调、掉帧时间戳定位

3.1 现象识别：从“感知卡顿”到“帧级别定位”

当用户反馈界面“卡了一下”或开发者通过 dumpsys gfxinfo 发现帧时长超过 16ms 的 spike 时，问题已经发生。但你是否能回答以下三个问题？

是哪一帧掉下来了？
那一帧的哪个阶段（输入、动画、布局、绘制）超时？
是哪个线程（UI 线程、RenderThread、GPU）阻塞了？

本章的工具就是用来将模糊的“卡顿感知”分解为精确的“帧级故障坐标”。

核心概念：Choreographer 是 Android 渲染管线的“心跳驱动器”。它每收到一个 VSYNC 信号，便依次回调注册的 FrameCallback、InputCallback、动画、遍历（measure/layout/draw）等任务。如果某个回调阻塞，后续所有任务（包括下一帧）都将延迟。

3.2 数据采集：三种帧级分析手段

分析手段	数据来源	采集方式	输出形式
FrameCallback	`Choreographer.FrameCallback`	应用代码注册回调，记录每次回调触发时间	时间戳序列
Choreographer 回调	系统日志 / `dumpsys` / Trace	`adb logcat -s Choreographer` 或 systrace	“Skipped 42 frames” 警告、回调时长
掉帧时间戳	`FrameMetrics` / `FrameCallback` 差分	两帧时间戳之差减去 16.67ms 取整	连续掉帧数、最大掉帧区间

3.3 原因定位：故障树与排查表

以下故障树帮助你将“帧抖动”逐级下钻到具体原因。

帧抖动 (Spike / Jank)
├── 帧间隔 > 16.67ms
│   ├── UI 线程阻塞 (Choreographer.doFrame 超时)
│   │   ├── Input 事件处理过长 (触摸响应、焦点切换)
│   │   ├── Animation 回调过重 (属性动画、自定义动画)
│   │   ├── View 遍历过重 (measure/layout 嵌套过深、ConstraintLayout 性能问题)
│   │   ├── draw 过长 (Canvas 绘制复杂路径、Bitmap 缩放)
│   │   └── 垃圾回收 (GC)
│   ├── RenderThread 阻塞 (帧提交延迟)
│   │   ├── 硬件加速缓冲区等待
│   │   ├── 启用了 Sync Barrier 但等待时间过长
│   │   └── RenderNode 更新开销
│   └── GPU 瓶颈 (GPU 渲染超时)
│       └── 过度绘制 / 纹理上传 / Shader 编译
└── 帧间隔 > 50ms  (严重冻帧)
    └── UI 线程被绑定操作或 IO 直接挂起

排查表：逐帧分析步骤
记录基准：在 Choreographer.FrameCallback 首行打印 System.nanoTime()，标记为 frameStartTs。
计算实际间隔：deltaMs = (frameStartTs[n] - frameStartTs[n-1]) / 1_000_000。
判定丢帧数：skippedFrames = (int)((deltaMs - 16.67) / 16.67)。如果 skippedFrames >= 1，这帧就是抖动帧。
标记异常帧区间：记录从 n-1 到 n 之间的时间戳窗口。
关联系统日志：在该时间窗口内搜索 Choreographer 的“Skipped”警告，或 WindowManager 的“input dispatching timed out”日志。

3.4 修复动作与复测：以时间戳反推阻塞点

假设你从 FrameCallback 中采集到了以下掉帧时间戳序列（单位 ms，相对基准）：

帧索引  实际开始时间  实际结束时间  帧耗时  掉帧数
  1         0.0         16.5       16.5     0
  2        16.5         32.1       15.6     0
  3        32.1        152.8      120.7     6   ← 抖动帧
  4       152.8        169.3       16.5     0
  5       169.3        185.6       16.3     0

定位逻辑：

帧3 的 实际开始时间 = 32.1ms，预期开始时间 = 48.78ms（32.1 + 16.67）。但实际开始于 152.8ms，说明 帧3 被延迟了约 120ms。
利用 Trace.beginSection("jankFrame3") 包裹帧3 的 doFrame 块，结合 systrace 查看 32ms→152ms 区间内 Choreographer 的回调是否被前序任务（如 performTraversals 或 Input）阻塞。
修复动作：如果 Systrace 显示 Choreographer.doFrame 内部 Input 花了 80ms，则优先排查触摸事件处理中的耗时代码（如 RecyclerView 的 getAdapterPosition、大量日志打点）。

复测：修复后重新运行相同操作，确认掉帧数归零。同时检查 FrameCallback 输出的 skippedFrames 列表不再出现超过 1 的条目。

常见陷阱：

FrameCallback 本身也会消耗少许时间（约 0.1ms），不要在回调内做复杂计算。
不要只依赖 Logcat "Skipped frames" 定位，因为该日志可能被系统裁剪，建议启用 adb shell setprop debug.choreographer.framelog 1 获取完整帧日志。
掉帧时间戳计算时，注意 System.nanoTime() 返回的是纳秒，务必转为毫秒比较。

3.5 预防：将帧级监控嵌入日常开发

自动化检查：编写 CI 脚本，从 FrameMetrics 中提取 totalDuration 数组，若存在连续两帧耗时 > 32ms，则标记构建为“卡顿待查”。
开发阶段 hook：在 debug 版本中全局注册 Choreographer.FrameCallback，当单帧耗时 > 50ms 时自动输出堆栈（使用 Thread.dumpStack()）。
导出至性能面板：将掉帧时间戳列表写入手写文件或 Firebase Performance 自定义追踪，在测试阶段覆盖各类用户操作路径。

3.6 帧级定位流程图

下图总结了从采集到定位的完整流程：