做性能优化这些年我越来越觉得Android 流畅体验的源头其实不在代码本身而在一个容易被忽略的信号里——VSync。只要你的 App 涉及界面刷新、动画、视频播放或者自定义渲染就绕不开它。很多开发者对 VSync 的理解停留在“屏幕刷新率”这个层面真要说起应用层怎么接收、怎么用往往一头雾水。这篇文章就从 App 开发者的视角把这个信号从产生到消费的链路整个拆开再给你几套可以直接抄的接收方案。这篇文章适合三类读者一是正在做自定义渲染引擎、被帧率不稳定折磨的开发者二是写视频播放器、需要做音画同步的人三是对 Choreographer 内部机制好奇、想在性能监控上做出点东西的人。看完之后你不仅知道 VSync 是什么还能照着文里的代码在项目里真实地接收到这个信号并把它用在帧率统计、逐帧渲染这些场景里。1. VSync 到底在哪一层产生App 又是怎么拿到的1.1 显示硬件的“心跳”VSync 信号的诞生先说最底层的逻辑。屏幕并不是一个字节一个字节地从左到右画完的它是一行一行扫描刷新的。每次扫描完成一整幅画面硬件就会产生一个垂直同步脉冲这就是 VSyncVertical Synchronization。这个信号对显示系统而言相当于心脏跳动——每一次跳动代表屏幕准备好接收下一帧画面了。在早期 Android 系统里应用任性地往屏幕缓冲区里写数据写的时候可能屏幕正在刷新一半于是画面就出现横向撕裂上半部分是旧帧下半部分是新帧。后来系统引入了 BufferQueue 和 SurfaceFlinger再用 VSync 作为全局同步机制才把整个渲染节奏统一起来。所以 VSync 不是一个能随便忽略的“辅助优化”而是 Android 渲染系统的基石。对 App 来说VSync 不是硬件直接发过来的中断它要经过 SurfaceFlinger 和系统进程的分发才能到达应用层。这里就得先搞清楚两类 VSync 的区别SF VSync 和 App VSync。SurfaceFlinger 自己会收到一个由硬件或虚拟时钟驱动的 SF VSync用于决定何时去合成各个 App 提交上来的 Buffer而 App 能拿到的则是 App VSync也就是系统以 SF VSync 为基础、再考虑当前窗口的显示状态后分发给应用进程的另一个同步信号。这两者通常是同一个节奏但又不完全相等理解这点对后面排查掉帧问题很有帮助。1.2 App 层为什么必须“主动”接收 VSync很多人会问App 的 UI 不是系统在管吗我干嘛要关心 VSync答案在于所有需要自己决定刷新时机的代码都必须和 VSync 对齐否则动画会忽快忽慢视频会音画不同步自定义渲染的帧率也会变得极其不稳定。举个例子你写了一个自定义 View用 Handler.postDelayed 每 16ms 发一次消息去触发重绘看起来是在做 60fps 的刷新。但 Handler 是基于 MessageQueue 的它的消息时间戳并不会和硬件 VSync 对齐。系统在下一个 VSync 到来时才会真正执行绘制也就是说你的消息可能在两个 VSync 之间挤进来结果就会出现某一次刷新跨了两个周期、下一次刷新又挤在同个周期里的情况帧间隔忽长忽短肉眼看到一卡一卡的。系统提供的正确姿势是 Choreographer。它会把你的回调注册到下一个 VSync 上保证你所有的帧工作都落在同一个节奏点。所以接收 VSync本质上不是为了“更快”而是为了“对齐”。谁先理解这一点谁就能把渲染类的代码写出稳定感。2. App 接收 VSync 的标准入口Choreographer2.1 Choreographer 是唯一“合法”的应用层入口Choreographer 翻译过来是“编舞师”很形象——屏幕上所有 UI 动作绘制、动画、输入事件处理都由它统一编排到 VSync 节奏上。ViewRootImpl 在每次屏幕需要刷新时会向 Choreographer 注册一个 Callback等 VSync 信号到来再按照回调队列依次执行 input、animation、traversal 这几个阶段。应用开发者注册自己的回调核心接口是postFrameCallback和postFrameCallbackDelayed。前者监听下一帧的 VSync后者可以设置延迟时间。回调里拿到的时间参数frameTimeNanos就是这一帧的 VSync 精确纳秒时间戳一般由 SurfaceFlinger 派发下来精度非常高。关键代码长这样Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() { Override public void doFrame(long frameTimeNanos) { // 拿到这一帧的 VSync 时间戳 long now System.nanoTime(); long frameInterval frameTimeNanos - lastFrameTimeNanos; lastFrameTimeNanos frameTimeNanos; // 在这里做你自己的逻辑比如统计帧间隔或驱动渲染 // 务必重新注册才能持续接收到下一帧 Choreographer.getInstance().postFrameCallback(this); } });每次回调执行完如果你还想继续监听下一帧必须再调用一次 postFrameCallback。很多新手在这里容易漏导致回调自动停下来还以为是系统没发信号了。2.2 理解 doFrame 里的 frameTimeNanosframeTimeNanos是理解整个机制的核心。它代表这一帧 VSync 发生的时间单位是纳秒基准是System.nanoTime()。注意它不是你回调真正执行的时间。如果主线程忙碌回调可能比这个时间晚几十毫秒才跑但时间戳依然是那个 VSync 的时间。所以用这个时间戳做帧间隔统计非常准。你只需要把两次 doFrame 的时间戳相减就能得到实际的帧间隔。如果屏幕是 60Hz理论间隔是 16.6ms如果是 120Hz就是 8.3ms。如果计算出的间隔明显大于理论间隔说明中间发生了掉帧。掉几帧也能算出来用实际的帧间隔除以理论帧间隔得到的数减一就是掉帧数。比如 60Hz 屏幕上两次 doFrame 的间隔是 50ms那就掉了大约两帧50/16.6 ≈ 33-1 2。这个逻辑是后续所有帧率监控工具的基础。2.3 在非 UI 线程能用 Choreographer 吗Choreographer 是线程绑定的内部通过 ThreadLocal 存储实例。默认你用Choreographer.getInstance()拿到的是 UI 线程那个实例但如果你在子线程调用它也会创建另一个属于该线程的 Choreographer。关键是这个实例和显示系统之间必须能正常通信它内部会创建一个 FrameDisplayEventReceiver通过与 SurfaceFlinger 的 Binder 连接来接收 VSync 事件。所以理论上你可以在任意线程创建 Choreographer然后用它来驱动这个线程上的渲染循环。但实际项目中我不太建议这么做原因有两个一是多线程各自拿到的 VSync 时间戳很难完全对齐容易造成逻辑同步上的细微误差二是非 UI 线程的 Choreographer 不受 ViewRootImpl 的约束在系统休眠或省电模式下可能会自己停掉。除非你写的是专门的渲染线程且对功耗有把握否则还是老老实实用 UI 线程的实例。3. 更精细的接收方式FrameMetrics 与回调节流机制3.1 用 FrameMetricsAggregator 收集渲染性能数据了解完 Choreographer再来看一个更“上层”的接收方式——FrameMetrics。它是 Android 7.0 引入的 API专门用于采集每一帧渲染的详细耗时包括 vsync time、animations duration、traversal duration、draw duration、sync duration、command issue duration、swAP buffers duration 等。它和 Choreographer 的区别在于Choreographer 是让你“跟随”每一帧的节奏去做事FrameMetrics 则是让你“观察”每一帧的耗时属于统计类工具。FrameMetricsAggregator aggregator new FrameMetricsAggregator(); aggregator.add(activity); // 在合适的时机比如离开页面或定期上报取出统计结果 SparseIntArray vsyncData aggregator.getMetrics(FrameMetrics.TOTAL_DURATION);上面这段代码可以统计整个页面所有帧的耗时分布。getMetrics返回一个直方图数组index 代表耗时区间value 代表该区间出现多少次。如果大量帧落在 16ms 以上的区间说明用户体验可能已经开始受到影响了。3.2 通过 OnFrameMetricsAvailableListener 实时接收如果你不想做整体统计想实时拿到每一帧的耗时可以用Window.addOnFrameMetricsAvailableListener。它能让你在每一帧渲染完成后立即收到回调而且是异步的不会阻塞主线程。window.addOnFrameMetricsAvailableListener(new Window.OnFrameMetricsAvailableListener() { Override public void onFrameMetricsAvailable(Window window, FrameMetrics frameMetrics, int dropCountSinceLastInvocation) { long vsyncTimeNanos frameMetrics.getMetric(FrameMetrics.VSYNC_TIME); long totalDurationNanos frameMetrics.getMetric(FrameMetrics.TOTAL_DURATION); // 处理你的数据 } }, new Handler());dropCountSinceLastInvocation特别有用它告诉你上一次回调之后系统丢了多少帧这是监控卡顿的核心指标。很多性能监控 SDK 就是用它来上报 jank 率的。3.3 回调节流为什么不会“叠加”执行在用 postFrameCallback 时有一个机制值得特别留意如果你在 doFrame 里又调用 postFrameCallback下一个 VSync 到来时它会执行一次但如果多个地方都注册了回调Choreographer 会把这些回调统一放到 CALLBACK_ANIMATION 或 CALLBACK_TRAVERSAL 的队列里等待同一个 VSync 事件来触发。这意味着一个 VSync 周期内你的回调最多执行一次无论你注册多少次都不会在下个周期里被“合并”执行。这个机制保证了即使代码写得再乱也不会一帧内重复刷新多次。但也带来了一个陷阱如果某个回调整体耗时超过了一帧的间隔下一个回调会继续迟到造成持续掉帧。官方建议在 doFrame 里只做轻量操作重活一定要移到后台线程或者用 IdleHandler 兜底。我见过有人在 doFrame 里做 SharedPreferences 写入结果一写完预览动画就开始闪眼睛排查了半天才发现是这里卡的。4. 实操做一个帧率监控与逐帧渲染的小工具4.1 基于 Choreographer 统计真实帧率理论说了这么多来点实际能用的。下面我给出一套帧率监控的完整实现可以直接粘到你项目里。class FpsMonitor(private val onFrame: (fps: Double, jankCount: Int) - Unit) { private var lastFrameTimeNanos 0L private var frameCount 0L private var jankCount 0L private var monitorStartNanos 0L private val frameCallback object : Choreographer.FrameCallback { override fun doFrame(frameTimeNanos: Long) { if (lastFrameTimeNanos ! 0L) { val interval frameTimeNanos - lastFrameTimeNanos val frameInterval 1_000_000_000L / refreshRate if (interval frameInterval * 2) { jankCount } frameCount } else { monitorStartNanos frameTimeNanos } lastFrameTimeNanos frameTimeNanos val elapsedNanos frameTimeNanos - monitorStartNanos if (elapsedNanos 1_000_000_000L) { val fps frameCount * 1_000_000_000.0 / elapsedNanos onFrame(fps, jankCount) frameCount 0 jankCount 0 monitorStartNanos frameTimeNanos } Choreographer.getInstance().postFrameCallback(this) } } private val refreshRate: Long get() 60L fun start() { Choreographer.getInstance().postFrameCallback(frameCallback) } fun stop() { Choreographer.getInstance().removeFrameCallback(frameCallback) lastFrameTimeNanos 0 } }refreshRate 我用了一个固定值实际开发中可以从 WindowManager 拿到屏幕真实刷新率val refreshRate context.display?.refreshRate?.toLong() ?: 60L帧间隔的判断条件我用了frameInterval * 2也就是间隔超过两帧才算一次 jank。这里有个细节如果掉了一帧interval 约等于 33ms如果掉两帧约等于 50ms。阈值取两帧可以过滤掉一些系统级调度噪声。4.2 用 FrameMetrics 统计 jank 分布用上面的方式统计帧率时主线程要持续回调多少有点负担。如果你想更轻量、更官方地统计掉帧情况可以换成 FrameMetrics。class JankStatsHelper(private val activity: Activity) { private val callback object : Window.OnFrameMetricsAvailableListener { override fun onFrameMetricsAvailable(window: Window, frameMetrics: FrameMetrics, dropCountSinceLastInvocation: Int) { val totalDuration frameMetrics.getMetric(FrameMetrics.TOTAL_DURATION) val vsyncInterval 1_000_000_000L / (activity.display?.refreshRate ?: 60f).toLong() if (totalDuration vsyncInterval || dropCountSinceLastInvocation 0) { // 这一帧发生了 jank } } } fun start() { activity.window.addOnFrameMetricsAvailableListener(callback, Handler(Looper.getMainLooper())) } fun stop() { activity.window.removeOnFrameMetricsAvailableListener(callback) } }注意dropCountSinceLastInvocation是累加值表示距离上一次回调后总共丢了几帧。如果你在前一次事件里已经上报过就需要自己记录下上次的丢帧数这次减去上次的才是当前帧造成的丢失数量。这个细节坑过不少人上报数据翻倍都是因为没做差值。4.3 在音视频渲染里按帧驱动除了监控接收 VSync 还有一个很实用的场景音视频播放器的逐帧渲染。当你要做一个自定义播放器不走系统 SurfaceView 的自动时序而是自己控制视频帧的显示时机时用 Choreographer 对齐 VSync 是最好的方案。思路是这样的解码线程通过 MediaCodec 解出视频帧并记录每帧的 pts显示时间戳主线程用 Choreographer 驱动渲染每收到一次 VSync判断当前系统时间和下一帧 pts 的差值如果到了该显示的时间就把这帧送到 Surface 上。这样做出来的播放器画面刷新节奏和系统一致不会出现视频和背景动画各跳各的观感。伪代码大概是Choreographer.getInstance().postFrameCallback { frameTimeNanos - val nextFrame decoder.nextFrameIfReady(frameTimeNanos) if (nextFrame ! null) { renderer.render(nextFrame) } Choreographer.getInstance().postFrameCallback(this) }这里有个经验不要在 doFrame 里做 MediaCodec 的 dequeueOutputBuffer因为这会触发 Binder 调用和解码器的内部锁耗时不可控。正确做法是让解码线程自行推进把解码好的帧放进一个有上限的队列里UI 线程只从队列里取帧。很多播放器架构里都有这个设计目的就是把解码的不可控延迟和 UI 的固定节奏解耦。5. 常见问题与排查技巧实录5.1 doFrame 回调持续迟到怎么办症状动画卡顿FpsMonitor 显示帧率在 30~45 之间跳动每次跳动间隔很有规律。排查思路先确认是不是主线程本身有耗时任务。用 adb 打一下主线程的栈adb shell debuggerd -b pid或者更直观一点adb shell dumpsys gfxinfo package framestatsframestats会输出最近 128 帧的详细时间记录包括 VSync 时间戳、App 开始绘制的时间、提交 Buffer 的时间。如果 VSync 时间戳和绘制时间差太远说明消息队列排队了如果绘制时间和提交时间间隔很大则说明是同步/渲染耗时。我遇到过一个真实案例某个界面在 doFrame 里做了一次 SharedPreferences 的 getString正常情况下也就零点几毫秒但因为 SP 文件很大、第一次加载要 readFully结果主线程被卡了 80ms动画直接跳帧。解决方案是把 SP 读取改成异步加载到内存 Map 里或者换 DataStore。5.2 子线程 Choreographer 收不到 VSync症状有些机型上子线程创建的 Choreographer 回调频率极低甚至不回调而 UI 线程的 Choreographer 正常。原因系统在屏幕休眠或者省电模式下会暂停对非活跃进程的 VSync 分发。UI 线程因为跟 ViewRootImpl 绑定系统会优先保证它的唤醒但子线程的 Choreographer 没有 View 层面的依赖就可能被系统当作“低优先级任务”直接挂起。对策如果是渲染引擎不要单独建一个线程去 postFrameCallback而是让渲染线程阻塞等待 UI 线程 Choreographer 发来的信号。用Choreographer.postFrameCallback把时间戳发到目标线程的 Handler 里再由那个线程去做渲染。这相当于用 UI 线程的 Choreographer 当“节拍器”具体干活的是后台线程两者通过 Handler 消息解耦。5.3 Choreographer 多实例冲突导致回调丢失症状页面里多个地方各自调用了Choreographer.getInstance().postFrameCallback结果部分回调执行部分没执行。原因Choreographer 的回调队列是全局共享的每次 VSync 到来会把队列里的所有 callback 执行一遍。但如果其中一个回调抛了异常且没被捕获整个 doFrame 流程会中断导致没执行的回调被丢弃。排查方法先全局开关捕获 Choreographer 回调里的异常。最容易出错的是第三方 SDK 里注册的 FrameCallback它们平时可能没问题一旦遇到特定机型的时间戳边界就会崩。建议在开发环境用一个自定义的 UncaughtExceptionHandler 打日志定位到具体类后再处理。Thread.currentThread().setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler() { Override public void uncaughtException(Thread t, Throwable e) { Log.e(ChoreographerTrap, Exception in thread t.getName(), e); } });5.4 用 dumpsys SurfaceFlinger 检查真实掉帧Choreographer 拿到的 App VSync 是系统分发的结果但实际显示链路里SurfaceFlinger 可能还会因为合成瓶颈再掉帧。想确认底层到底掉没掉帧可以直接查 SurfaceFlinger 的帧记录adb shell dumpsys SurfaceFlinger --latency输出的是一个二维表每行代表一个显示帧三列分别是Desired-present-time、Actual-present-time、Frame-ready-time。用 Actual-present-time 减去 Desired-present-time如果差值大于一个 VSync 周期说明这一帧交付晚了可能引发用户可见的 jank。这个命令在比较新的 Android 版本上参数有所调整也可以用adb shell dumpsys SurfaceFlinger --latency layerName来指定是哪个 Surface。不过它是全局调试工具只能帮你确定问题是在 App 层还是合成层具体细节还是要靠代码排查。5.5 refreshRate 与 VSync 频率不一致现在高刷屏越来越普及但有些 App 依然假设屏幕是 60Hz导致帧间隔按 16.6ms 来计算统计出来的掉帧数完全是错的。正确做法是动态获取刷新率val refreshRate: Float get() if (Build.VERSION.SDK_INT Build.VERSION_CODES.R) { displayManager.display?.refreshRate ?: 60f } else { Suppress(DEPRECATION) display?.refreshRate ?: 60f }Android 11 之后display 的获取方式改了需要通过DisplayManager来拿。如果你的应用支持 Android 10 以下得把两个分支都写出来。另外部分机型还支持可变刷新率如 60/90/120Hz 动态切换你统计帧率时如果发现刷新率变了要重新初始化阈值否则监测会失灵。6. 应用到实际项目帧率监控、动画驱动与性能上报6.1 自定义帧率统计 SDK 的设计要点如果你想把 VSync 接收能力整合成一个内部 SDK我有几个建议。对外暴露一个start()方法内部用 Choreographer 采集帧间隔但上报数据不要直接在回调里发网络请求而是先写到内存队列再定期批量上报。这样即使回调很频繁也不会给网络线程造成压力。还要处理生命周期。Activity 或 Fragment 销毁时务必调用removeFrameCallback否则会泄漏 Activity 引用。这一点坑过不少人Choreographer 的回调会持有你传入的 FrameCallback 对象如果你在回调里再持有了 Activity整个 Activity 就永远释放不掉了。一个比较好的做法是SDK 内部只持有 ApplicationContext 和 Listener不持有具体页面引用。页面在 onResume 时调用beginSession(pageName)onPause 时调用endSession()SDK 负责把当前页面的帧数据关联到本次会话里。6.2 用 VSync 驱动动画的节奏控制在自定义动画引擎里我推荐以 Choreographer 作为驱动源而不是 Handler postDelayed 或者 ObjectAnimator。前者能保证动画的每一帧都落在系统刷新点上不会出现帧间间隔不均。实现时需要自己做一个“动画时钟”class VsyncAnimationClock(private val onTick: (Long) - Unit) { private var startTime 0L private val callback object : Choreographer.FrameCallback { override fun doFrame(frameTimeNanos: Long) { val elapsed (frameTimeNanos - startTime) / 1_000_000 onTick(elapsed) Choreographer.getInstance().postFrameCallback(this) } } fun start() { startTime System.nanoTime() Choreographer.getInstance().postFrameCallback(callback) } fun stop() { Choreographer.getInstance().removeFrameCallback(callback) } }然后你的动画执行器根据 elapsed 计算当前进度更新属性。如果中间发生了掉帧进度会直接跳到对应位置不会像 Handler 那样出现“追赶”效果。这个追赶效果非常恶心比如动画本来该在 300ms 完成因为掉帧变成了 350ms 才执行完用户会觉得动画“拖沓”。6.3 性能监控上报时的数据聚合策略最后说一下上报策略。收到 VSync 信号之后你拿到的是一堆单个帧的数据直接上报的流量和存储压力都很大。业界一般有两种聚合方式一是按时间窗口聚合每 5 秒或 10 秒汇总一次帧数、掉帧数、丢弃帧数等二是按页面会话聚合整个页面存活期间只上报一个综合指标上线时更加稳定。我倾向第二种。页面维度上报 jank 率jank 帧数 / 总帧数比秒级上报更准确因为秒级数据受系统调度影响较大波动明显而页面级数据更能反映真实用户体验。具体实现时监听onFrameMetricsAvailableListener每次回调里累加isJank的布尔值页面销毁时统一计算。这里还有个值得注意的小细节上报前要对数据进行“异常值过滤”。如果设备刚开机系统还不稳定帧率数据可能会异常偏高或偏低。可以先缓存最近 3 秒的数据发现数据剧烈波动时重新计算一次确认是设备本身的问题还是系统降频引起的再决定是否上报。这个处理能避免监控平台的误报。接收 VSync 这件事表面上看只是调一个 API实际背后涉及显示链路、调度机制、生命周期、线程模型等多个层面的配合。我做了这么久性能优化最大的体会就是真正稳定的 App 不是靠哪一段代码写得漂亮而是靠那些看不见的节奏——VSync 就是 Android 世界里最基础的节奏弄懂它你就能把自己的渲染代码、动画代码和视频播放代码都编排到这个不可见的乐谱里。接到信号只是第一步更重要的是理解信号背后的时序逻辑然后顺着它去设计你的代码结构。希望这篇文章能帮你省下一些在帧率泥潭里挣扎的时间。