Android的渲染流程并非一次简单的draw调用，而是涉及主线程测量布局、绘制指令录制、RenderThread执行GPU合成、SurfaceFlinger最终上屏等多个阶段。任何一个环节耗时超过16.6毫秒，用户就会感知到掉帧。以往开发者习惯在onDraw方法前后手动打点计时，但这种方式只能覆盖部分绘制耗时，无法反映完整的帧生命周期。Frame Metrics API的出现，为开发者提供了一个系统级的观测窗口：它能够汇报每一帧从开始调度到最终显示在屏幕上的细致时间分解，包括输入处理、动画、测量布局、绘制、同步、提交等多个独立阶段。
要理解Frame Metrics的价值，必须先搞清楚Android帧渲染的两级循环机制。应用侧由Choreographer驱动，注册VSYNC信号回调后，依次执行输入回调、动画回调、遍历视图树的measure和layout、执行draw生成DisplayList。这一系列操作都在主线程完成，产物会通过RenderThread与GPU进行合成。系统侧的SurfaceFlinger再根据不同layer的合成策略，最终把画面送到硬件显示控制器。Frame Metrics通过Android的FrameMetricsObserver接口，向系统请求监听每一帧的时间戳，这些时间戳由Choreographer、RenderThread以及SurfaceFlinger共同填写，因此数据远比应用内打点全面。
Frame Metrics API的工作原理与关键指标
Frame Metrics的核心类是Window.FrameMetricsObserver，它需要绑定到某个Window上。应用获取Window对象后，调用addFrameMetricsObserver注册监听，系统就会在每一帧渲染完成后回调onFrameMetricsAvailable方法，携带一个包含若干时间戳的整型数组。这些时间戳以纳秒为单位，数组下标对应不同的帧阶段常量，开发者通过Window.FrameMetrics中的静态常量来索引。
关键指标包括INDEX_FRAME_TIMELINE_VSYNC（VSYNC信号到达时间）、INDEX_INPUT_HANDLING_START（输入事件开始处理）、INDEX_ANIMATION_START（动画开始）、INDEX_PERFORM_TRAVERSALS_START（测量布局开始）、INDEX_DRAW_START（绘制开始）。此外还有INDEX_SYNC_START表示RenderThread开始同步绘制指令、INDEX_ISSUE_DRAW_COMMANDS_START表示GPU开始执行绘制命令、INDEX_SWAP_BUFFERS表示缓冲交换完成、INDEX_FRAME_COMPLETED表示帧已经提交给SurfaceFlinger。终端显示时间则需要额外调用INDEX_DISPLAY_PRESENT_TIME，但这个值在部分系统版本上可能缺失，需要做空值判断。
值得注意的一点是，Frame Metrics返回的是相对时间戳，并非从系统开机以来的绝对耗时，而是相对于某一帧提交开始的时间差。多数情况下开发者更关心各阶段之间的差值，例如用INDEX_FRAME_COMPLETED减去INDEX_INTENDED_VSYNC得到整帧的总耗时，用INDEX_DRAW_START减去INDEX_PERFORM_TRAVERSALS_START得到测量布局耗时。由于不同设备厂商可能会对时间戳的填充逻辑做定制，正式项目里最好对关键差值做合理性校验，过滤掉明显异常的数据。
在Android应用中集成Frame Metrics采集帧耗时
集成Frame Metrics并不复杂，但需要处理Window引用的生命周期。一个常见做法是在Activity的onAttachedToWindow中注册观察者，在onDetachedFromWindow中移除，避免Window销毁后产生悬空引用。下面是一段Kotlin示例，用于注册帧观察者并打印每一帧的总耗时与绘制耗时。
class FrameMetricsActivity : AppCompatActivity() {
private var frameMetricsObserver: Window.FrameMetricsObserver? = null
override fun onAttachedToWindow() {
super.onAttachedToWindow()
val observer = Window.FrameMetricsObserver(
window,
Handler(Looper.getMainLooper())
) { _, metrics ->
val totalDuration = metrics[Window.FrameMetrics.INDEX_FRAME_COMPLETED] -
metrics[Window.FrameMetrics.INDEX_INTENDED_VSYNC]
val measureLayoutDuration = metrics[Window.FrameMetrics.INDEX_DRAW_START] -
metrics[Window.FrameMetrics.INDEX_PERFORM_TRAVERSALS_START]
val drawDuration = metrics[Window.FrameMetrics.INDEX_SYNC_START] -
metrics[Window.FrameMetrics.INDEX_DRAW_START]
Log.d("FrameMetrics", "总耗时=${totalDuration / 1_000_000f}ms, " +
"测量布局=${measureLayoutDuration / 1_000_000f}ms, " +
"绘制=${drawDuration / 1_000_000f}ms")
}
window.addFrameMetricsObserver(observer)
frameMetricsObserver = observer
}
override fun onDetachedFromWindow() {
super.onDetachedFromWindow()
frameMetricsObserver?.let { window.removeFrameMetricsObserver(it) }
frameMetricsObserver = null
}
}
上面的代码中，Window.FrameMetricsObserver的构造函数接受三个参数：当前Window、一个Handler用于回调线程、以及一个回调函数。回调函数内接收两个参数，第一个是Window对象，第二个是长整型数组。数组长度为Frame Metrics定义的常量总数，但某些位置可能为0或负数，表示该阶段未被记录。因此在实际采集时，最好先判断关键索引的值是否大于0，再计算差值，避免出现负耗时。
对于Java项目，同样的逻辑可以写成匿名内部类。需要注意的是，回调默认运行在传入的Handler所在线程，如果传主线程Handler，那么回调会在主线程执行。频繁打印日志会干扰性能，实际监控中应该把原始数据写入内存缓冲区，批量交给后台线程处理。另外，如果Activity使用硬件加速，部分较早的API级别上Frame Metrics可能不可用，建议在注册前检查Build.VERSION.SDK_INT，最低要求API 24（Android 7.0）。
解析Frame Metrics数据并识别慢帧类型
拿到每一帧的时间戳数组后，只计算总耗时远远不够。慢帧的成因多种多样：可能是主线程执行了复杂的布局计算，可能是View的onDraw里创建了大量对象触发GC，也可能是GPU提交阶段因为纹理上传导致同步阻塞。通过Frame Metrics的阶段划分，可以快速缩小排查范围。假设某一帧总耗时30毫秒，其中测量布局耗时18毫秒，绘制耗时仅2毫秒，那么问题大概率出在布局嵌套过深或者约束条件复杂。反过来如果测量布局只有3毫秒，但同步阶段（INDEX_SYNC_START到INDEX_ISSUE_DRAW_COMMANDS_START）耗时超过15毫秒，则需要检查是否在渲染线程执行了重型操作，比如大位图解码或过度使用阴影效果。
为了直观分析，可以维护一个简单的分布统计：按总耗时将帧分为绿色（小于16.6毫秒）、黄色（16.6到33.3毫秒之间）、红色（大于33.3毫秒），然后分别统计每个颜色区间内各阶段平均耗时。这种聚合方式可以避免单帧噪声，更容易看出系统性问题。下面是一段伪代码，演示如何对采集到的帧数据做分类统计。
public void analyzeFrame(long[] metrics) {
long intendedVsync = metrics[Window.FrameMetrics.INDEX_INTENDED_VSYNC];
long frameCompleted = metrics[Window.FrameMetrics.INDEX_FRAME_COMPLETED];
if (intendedVsync <= 0 || frameCompleted <= 0) return;
long total = frameCompleted - intendedVsync;
long measureLayout = metrics[Window.FrameMetrics.INDEX_DRAW_START] -
metrics[Window.FrameMetrics.INDEX_PERFORM_TRAVERSALS_START];
long draw = metrics[Window.FrameMetrics.INDEX_SYNC_START] -
metrics[Window.FrameMetrics.INDEX_DRAW_START];
long sync = metrics[Window.FrameMetrics.INDEX_ISSUE_DRAW_COMMANDS_START] -
metrics[Window.FrameMetrics.INDEX_SYNC_START];
if (total < 16_600_000L) {
greenFrames.total += total;
greenFrames.measureLayout += measureLayout;
greenFrames.draw += draw;
greenFrames.sync += sync;
greenFrames.count++;
} else if (total < 33_300_000L) {
yellowFrames.total += total;
yellowFrames.measureLayout += measureLayout;
yellowFrames.draw += draw;
yellowFrames.sync += sync;
yellowFrames.count++;
} else {
redFrames.total += total;
redFrames.measureLayout += measureLayout;
redFrames.draw += draw;
redFrames.sync += sync;
redFrames.count++;
}
}
上面的Java代码中，Window.FrameMetrics.INDEX_DRAW_START等常量需要导入android.view.Window.FrameMetrics。需要注意的是，Frame Metrics提供的时间戳在部分设备上可能缺失INDEX_ISSUE_DRAW_COMMANDS_START，此时sync计算出来会是负数，聚合时需要先判断是否有效。实际项目中还可以结合Choreographer的FrameCallback来获取帧率，当帧率低于55时触发Frame Metrics采样，避免持续观察带来的性能开销。
结合dumpsys gfxinfo与常见误区提醒
Frame Metrics虽然能提供应用侧的帧时间分解，但它无法完全看到系统合成阶段的耗时，比如SurfaceFlinger的合成延迟、GPU驱动层的排队时间。因此官方建议结合dumpsys gfxinfo命令一起使用。在命令行执行adb shell dumpsys gfxinfo 包名可以输出应用的帧统计概览，包括总帧数、平均帧耗时、卡顿帧数量，以及细分到每个渲染阶段的毫秒数。尤其是Janky frames一栏，会列出超过16毫秒的帧在每个耗时桶中的分布，这可以和Frame Metrics采集到的实时数据互相印证。
这里必须纠正两个常见误区。第一个误区是认为帧总耗时等于主线程忙的时间。实际上从VSYNC信号到帧完成，中间包含了主线程之外的渲染线程执行和GPU等待，如果主线程快速完成了绘制指令录制，但渲染线程因为纹理上传或着色器编译导致同步阶段阻塞，主线程即使空闲也无法开始下一帧，因为Choreographer的VSYNC回调可能被跳过。第二个误区是单看某一帧的耗时峰值就下结论。由于Android调度器的不确定性，偶尔出现一两个高耗时帧可能是后台服务抢占或页面刚启动的瞬时负载，连续多次出现同一阶段的峰值才值得深入排查。所以采集时至少要保留最近几百帧的数据，结合平均值、P95、最大值来看。
构建一个可靠的帧耗时监控系统，除了数据采集和解析，还需要考虑上传策略。不建议每帧都实时上报，可以先在本地做聚合，每隔几秒或当卡顿帧比例超过阈值时再上传快照。同时要带上设备型号、系统版本、应用版本号等信息，方便后续做多维分析。如果团队已经接入了APM平台，可以把Frame Metrics数据作为自定义性能指标接入，配合现有的ANR、启动耗时监控，形成完整的客户端性能观测体系。
Android Frame Metrics帧渲染时间掉帧分析修改时间：2026-09-29 19:33:13