1. 先搞清楚“显示链路”到底在讲什么
1.1 显示链路不是单一模块，而是三层协作
很多做Android开发的工程师，调了两年UI，也是最近才知道屏幕上那个像素是靠一整套链路推上去的。单看一个层面，App只知道自己在画、SurfaceFlinger只知道自己在合成，谁都不会觉得自己是“显示链路”的一部分。只有把应用层、系统服务层、硬件层串成一条线，你才会看懂为什么有时候App不卡但屏幕卡，为什么掉帧不一定是主线程的问题。
我习惯把这个链路类比成寄快递：App是发货方，产出一个个“画面包裹”；WindowManager和SurfaceFlinger是快递中转站，负责贴单、分拣、排队；屏幕是最终收件人，要按固定节奏签收每一个包裹。任何一个环节出错——包裹内容太大、转递交接过慢、收货节奏不匹配，最后看到的都是卡顿、花屏或者黑屏。理解Android显示完整链路，本质上就是在理解这条物流线是怎么把一帧一帧画面送到屏幕上的。
1.2 一张图的核心脉络：从draw到display
如果你要画一张图，这张图的主干一定是一条直线，而这条直线上的每个节点都是一个经典问题：
- App侧收到VSYNC信号，开始测量、布局、绘制；
- 绘制后的像素被写入一个Surface对应的BufferQueue里；
- 应用进程通过Binder把这个Buffer交给WindowManager和SurfaceFlinger；
- SurfaceFlinger拿到所有应用窗口的Buffer，按照层叠顺序做合成；
- 合成结果交给硬件合成器HWC，最终输出到物理屏幕。
这张图有个特别容易让人误解的点：App并不是直接把画面画到屏幕，而是画到自己的Surface上。每个App只对“自己的那一层”负责，系统层做的事情是“把所有层合成一张总图”。一旦你接受了这个设定，后面所有细节都能顺理成章地理解。本文就是围绕这根主线，把每个节点展开成实际操作中可验证、可排查的知识点。
2. 应用侧的一生：从测量布局到将图像送入Surface
2.1 谁驱动UI刷新：Choreographer的召唤机制
应用侧的起点不是onDraw()，而是Choreographer。这个类是应用进程里最容易被忽略的“领航员”。正常情况下，屏幕每隔16.6ms会发出一次VSYNC（Vertical Synchronization），也就是垂直同步信号。而Choreographer会监听这个信号，然后回调到应用的消息队列里，触发一帧UI的整个绘制流程。
具体来说，Choreographer收到VSYNC后会回调FrameDisplayEventReceiver，接着调用doFrame()。在doFrame里，它会依次执行三个任务：用户触发的输入事件（input）、动画更新（animation）、以及遍历视图树（view traversal）。这三个任务合起来，才是一帧UI的完整“生命周期”。如果你主线程里某个耗时操作阻塞了Looper，Choreographer即使收到了VSYNC，也只是往消息队列里插了个“待命”回调，得等阻塞结束才真正doFrame。这就是为什么我们常说“主线程卡顿 = UI掉帧”，本质上就是Choreographer的节奏被打乱了。
2.2 真正的“画布”不是View，而是Surface
很多入门者以为View就是画布，直接在上面画。其实View只是一个普通的视图结构树节点，它负责提供布局和绘制指令，真正承载像素数据的是Surface。
每个Window都会对应一个Surface，这个Surface内部维护一块可被图形缓冲区管理的内存区域。应用侧无论是在onDraw()里用Canvas画出2D指令，还是通过RenderThread执行GPU硬件加速，最终都是把像素写到这块Surface上。写完后，这个Surface并不是直接出现在屏幕上，而是会被包装成一个“生产者的产出物”，放入BufferQueue等待系统拿走。
这里有两个概念要区分：一个是接口层面的Surface，App通过它获得Canvas或硬件渲染接口；另一个是数据层面的GraphicBuffer，它才是真正被传输的像素数据。我之前调试过一个花屏问题，最后发现就是Surface的尺寸和buffer实际尺寸不一致，导致合成时采样的数据和预期对不上。这种事只看View代码是永远看不出来的，必须把视角拉到Surface这一层。
2.3 应用把帧交给谁：BufferQueue的“排队进站”
App画完一帧，并不会强行插入显示队列。它会把写好的GraphicBuffer放进一个叫BufferQueue的队列里，等着系统来取。这个队列是一个典型的生产者-消费者模型，生产商是App侧渲染管线，消费者是SurfaceFlinger。
BufferQueue里通常有多个Buffer槽位。应用请求一个dequeueBuffer（从队列取出可写buffer），写完后调用queueBuffer（把buffer放回队列并标记为“完成待消费”）。而SurfaceFlinger需要合成时，会从队列中取走最新的一到多个已完成的Buffer，经过合成再释放回池中。
理解这一节最关键的收获是：App每帧的提交并不是同步阻塞的。如果你App画得慢，SurfaceFlinger并不会等它，而是可能拿着上一帧继续刷新屏幕。这个机制会在后面讲VSYNC和掉帧时彻底展开。现在你只需要记住：Surface是画布，BufferQueue是提交通道，App的每一帧画完之后都在这个通道里排队等消费。
3. 系统侧的“快递中转”：WindowManager到底管在哪一环
3.1 Window不是View，是Surface的“容器”
Android里经常听到“WindowManager”这个词，但很多人说不清Window到底是什么。简单说，Window是一个顶层窗口的抽象，它表示屏幕上的一块矩形区域，也是应用进程与系统在合成阶段交互的最小单位。一个App可以拥有多个Window，但每个Window都绑定着一个独立的Surface。
WindowManagerService（WMS）做的事情，就是为这些Window管理生命周期、计算显示区域、决定层叠顺序，并把这些元数据同步给SurfaceFlinger。比如你在AndroidManifest里声明了一个Activity，启动后系统会通过WindowManager.addView()把它的DeCorView挂到一个Window上。这里的关键节点是WindowManagerGlobal.addView() -> WindowManagerService.addWindow()，最终会创建一条Socket链路并分配Surface。
需要注意的是，WMS并不负责像素数据的合成，它只负责“排座位”。真正控制每个Surface如何分层、谁在上面谁在下面，是WMS通过一个叫WindowState的数据结构来描述的，它会维护窗口在屏幕上的坐标、大小、z轴层级、透明区域等信息。当窗口状态变化时，WMS会向SurfaceFlinger发送新的Layer参数，SurfaceFlinger根据这些参数做合成。
3.2 Z-order与每个App的“一张票”
Z-order是窗口显示在上层还是下层的排序依据。WMS会根据窗口类型、栈顺序、以及是否存在焦点窗口来算出一个Z轴数值，所有窗口按这个数值做全局排序。你可以用下面这个简表理解常见窗口类型的优先级：
| 窗口类型 | 典型场景 | Z轴优先级 |
|---|---|---|
| System Alert | 权限弹窗、悬浮窗 | 较高 |
| Application | Activity主窗口 | 正常 |
| Input Method | 软键盘 | 高于应用窗口 |
| Screen Shot | 截图类型 | 特殊范围 |
| Wallpaper | 壁纸 | 最低层级 |
Z-order一旦搞错，就会出现“窗口消失”“层被盖住”“触摸区域异常”等莫名其妙的问题。我遇到过一种情况，某个手势导航悬浮窗在System Alert层，但它的Surface大小比可见区域更大，导致下层应用的按钮被无形遮住，点击响应区域全部偏移。排查的时候盯着View层级看了一下午，最后还是通过dumpsys window windows对比了窗口的z序和frame，才定位到问题。所以说，WMS这块光懂“有窗口概念”是不够的，还要真能动手去看它的层级数据。
SurfaceFlinger吃的不是View树，而是WMS整理好的窗口属性表。这个属性表决定了它在合成时把每层Buffer摆在哪里、放大还是缩小、要不要做裁剪。到了这一层，就接近显示链路的真正下半场了。
4. SurfaceFlinger：如何把上百层UI合成一帧
4.1 SurfaceFlinger是什么：所有Surface的“终极调度员”
SurfaceFlinger是Android系统中负责绘制合成和最终显示的系统服务。它接收来自所有App进程的Surface，以及WMS同步过来的窗口元数据，通过合成算法生成一帧最终的图像，然后提交给显示硬件。
可以这样理解：每个App在私下里画自己的画，画完贴到一张透明胶片上；SurfaceFlinger拿着所有胶片，在桌面上按顺序叠放好，再整体拍照给投影仪。App互相之间并不知道对方画了什么，只有SurfaceFlinger掌握全局。
这里有一个容易误解的点：SurfaceFlinger不是简单地叠加图像，它还需要考虑每一层的可见区域、遮挡关系、透明度、缩放、色彩空间转换，甚至动态刷新率切换。在Android 8.0之后，SurfaceFlinger还加入了setFrameRate之类的接口来支持可变刷新率显示。所以它既是合成器，也是一个拥有显示策略的“中枢调度器”。
4.2 合成不是“PS图层简单合并”：GPU合成与HWC
SurfaceFlinger的合成路径通常有两种：OpenGL/GPU合成和硬件合成器（HWC）合成。
GPU合成就是SurfaceFlinger通过OpenGL或Vulkan绘制所有Layer到一个目标buffer中。这种方式灵活，可以做各种特效，但CPU和GPU消耗大。HWC是显示硬件提供的合成模块（比如高通的DPU），它可以直接把多个硬件图层叠加到物理显示上，不占用GPU的通用渲染管线。Android系统启动时，会在hardware.hwcomposer中注册若干Driver来支持这两种路径叠加。
实际合成过程是SurfaceFlinger遍历每个Layer，判断哪些Layer可以交给HWC合成，哪些必须走GPU合成。比如视频播放器的Surface经常是硬件专用层（protected buffer），不能被SurfaceFlinger读出来做GPU合成，就必须留给HWC。于是你会看到混合模式：某些层走GPU画进一个target buffer，再把这个buffer和几个video层一起交给HWC合并输出。
这个机制带来的坑就是：如果显示驱动没有配置好HWC层数，系统为了兼容会把所有层都交回GPU合成，结果导致GPU压力剧增、功耗上升、甚至掉帧。所以排查显示性能问题时，不能只盯着App，还要用dumpsys SurfaceFlinger判断当前合成是不是走了HWC。
4.3 BufferQueue到Layer：Binder传递的“大块头”怎么搬运
App进程和SurfaceFlinger进程之间的数据传输不能直接把像素内存拷来拷去，否则一帧4K画面就是几十MB带宽，必然卡死。Android利用了共享内存和一些优化手段，最核心的是GraphicBuffer，它内部通过Binder传递一个文件描述符（fd）或共享内存映射，让SurfaceFlinger直接映射到同一块物理内存，而不是复制像素数据。
具体路径是：App侧的BufferQueueProducer把已经填充好的GraphicBuffer，通过queueBuffer调用的Binder事务，把它对应的Binder节点传给SurfaceFlinger侧。SurfaceFlinger拿到协议后，会将这个GraphicBuffer映射到自身的地址空间，然后用于合成。整个过程像素物理内存只存在于一份，多个进程通过共享映射访问。
理解这点，你就能解释为什么内存抖动会严重拖慢显示链路：当App创建大量GraphicBuffer时，底层的ion/DMA-BUF分配压力会变大，等待分配的binder调用会变长，最终导致SurfaceFlinger拿不到新Buffer，出现jank。很多人优化渲染只看代码里的draw耗时，却忽略了buffer分配策略，这也是我反复强调“显示链路是整体”的原因之一。
5. VSYNC与缓冲机制：为什么卡顿不只是App的锅
5.1 VSYNC到底是什么信号
VSYNC是垂直同步信号，它由显示硬件在每次刷新周期的起始时刻产生。Android利用这一信号把应用绘制、合成、显示三者拉到同一个“节奏表”上。
每一次VSYNC，App侧的Choreographer醒来开始绘制，SurfaceFlinger在同一时间点也从BufferQueue中收集已就绪的Buffer进行合成。这个机制保证了“生产”和“消费”之间的节奏不脱节。如果没有VSYNC，App可能在屏幕刚刷新到一半时提交数据，造成画面撕裂（tearing）。有了VSYNC后，大家对齐刷新周期，撕裂问题就只会在极端情况发生。
Android系统里还区分了app vsync和sf vsync。简单理解就是帧绘制的发令枪响了两次：一次落在App主线程/渲染线程，一次落在SurfaceFlinger合成线程。这两次它们可以通过偏移量微调，目的是让App有更充裕的时间绘制，而合成线程刚好在Buffer送达后取出。
5.2 双缓冲与三缓冲的取舍
大家最熟悉的掉帧原因是App绘制耗时超过16.6ms，但这不等于一定会发生真正的掉帧。关键在于缓冲机制缓冲了多久。
常见的场景是双缓冲：BufferQueue里有两个Buffer轮流用，一边SurfaceFlinger消费一个，一边App生产另一个。如果App耗时超过一个VSYNC，它必须等下一个Buffer从消费者那边释放出来才能继续写，这样即使只画了17ms，也会被拖到第二个、甚至第三个VSYNC周期，造成一两个帧跳跃。
三缓冲则多了一个备用Buffer，App在SurfaceFlinger用着buffer A时，还能继续写buffer B和C。它不能消除掉帧，但能让掉帧更平滑，降低可见卡顿的频率。Android的大多数设备默认三缓冲。所以当你用Choreographer看到掉帧统计时，别急着怪App，先想想是不是因为BufferQueue里没有可用的Buffer，导致整个绘制周期被延后。
5.3 什么时候真的卡：四个关键等待点
从一帧从产生到显示，至少有四个环节会产生等待，任何一个等待过长，都会让用户感知到“卡”。
- App主线程/渲染线程排队：主线程消息里堆积任务过多，doFrame到达后迟迟不能执行。
- BufferQueue无缓冲可写：消费者还没释放前一个buffer，dequeueBuffer等待时间过长。
- SurfaceFlinger合成阶段的排队：合成线程负载高，或者等待app的空闲buffer通知。
- HWC和面板实际提交的延迟：硬件合成器响应慢，或者屏幕在fifo提交时发生刷新等待。
排查性能问题时，建议先用systrace或Perfetto抓取包含vsync的trace，再看每个等待阶段停留的时间。这样定位问题才能精确到“App侧占用高”还是“SurfaceFlinger等待长”，而不是笼统地说“掉帧了”。
例如：如果是因为主线程执行了SQLite查询导致耗时，那么在trace里会看到主线程等待后Choreographer回调的doFrame推后，其他线程则在等待同一帧。如果是因为SurfaceFlinger合成超时，则能看到out fence迟迟不释放。两个现象都掉帧，但根源完全不同，修法也完全不同——前者要改业务逻辑，后者要查图形驱动或显示HAL实现。
6. 我在排查显示问题时的几条实用经验
6.1 如何用adb命令看到一帧的“来龙去脉”
纸上谈兵容易，真正要排查问题还得靠工具。我这里分享几个我常用的命令，基本能覆盖显示链路的前半段到后半段。
adb shell dumpsys SurfaceFlinger --latency：查看每个窗口最近N帧的呈现时间戳。如果时间戳间隔出现明显抖动，可以快速判断当前窗口有没有掉帧。adb shell dumpsys window windows：查看窗口列表、z序、可见状态、大小。当你怀疑某个窗口遮挡或层级错乱，这个命令最直接。adb shell dumpsys SurfaceFlinger --list：列出当前系统中所有Layer的名称和标志，可以快速确认SurfaceFlinger是否在跟踪某一层Surface。adb shell dumpsys gfxinfo <package>：查看GPU绘制相关信息，包括帧时间直方图、jank数。
拿--latency来说，它的输出格式类似：
SurfaceFlinger pid: 1534 android.view.SurfaceControl#name 0 1617117900000000 1617117910000000 1617117920000000 1 ...每行表示一帧的三个时间戳：申请时间、完成时间、呈现时间。如果相邻完成时间差基本稳定在16666667ns以内，说明帧率稳定；一旦出现成倍间隔，就是掉帧了。我建议把这个输出保存成文件，用脚本统计间隔分布，比肉眼看快很多。
6.2 常见的误区：把掉帧都归咎于主线程
现在的App很多已经用Compose或自定义高规格渲染，有时主线程很空，但屏幕依旧会有周期性的卡顿。这时最常背锅的是SurfaceFlinger和硬件合成层。
我自己遇到过一个案例：某设备上相机页面很卡，主线程和方法耗时都很低，但预览帧率却到不了30fps。跑Perfetto看，发现相机预览的Surface在合成时每次都要转型成YUV数据，而目标设备不支持硬件层直接输出YUV，只能走GPU合成和转换。后来通过在相机的Surface设置合适的Format并调整HDR/动态范围标志，才让合成器走上HWC路径。这种事你用adb shell dumpsys SurfaceFlinger --latency只能看到“帧到得慢”，但看不到“为什么慢”，必须配合dumpsys SurfaceFlinger里的layer信息去排查是格式不相容还是buffer数量不足。
所以我的建议是，不要拿“绘制耗时不长”当绝对结论。显示链路的瓶颈常常在“传输格式”“合成路径”和“buffer分配”这些更靠后的环节。遇到掉帧，先把SurfaceFlinger的合成路径查清楚，再回到App写代码。
6.3 画一张属于你自己的显示链路图
最后，我强烈建议你不要直接背别人的链路图。你可以在自己的开发机上，亲手运行一个简单App，然后串一遍从Activity.finishDraw到SurfaceFlinger推送的完整流程。给每个关键点打一个log，观察日志先后顺序。这样画出来的图才是你的底层心智模型。
比如你可以这样操作：
- 在
ViewRootImpl.performTraversals()里加横跨主线程和渲染线程的log； - 在
Choreographer.doFrame()里打帧序号； - 在
BufferQueue的生产者端和消费者端观察一次dequeue/queue事务； - 再用
dumpsys SurfaceFlinger --latency看最终呈现时间。
这个过程不一定一次做完，但强烈建议在模拟器或真机上跑一遍。等你实操完，你会发现原来“一张图看懂Android显示完整链路”并不是一句玩笑话——它其实是一个可以测量、可以验证、可以被拆解成工具调用链路的工程问题。
我自己反复画过这张图很多次，每画一遍，对显示链路的理解就更深一分。你可以先从最粗的“App -> SurfaceFlinger -> HWC -> Display”开始，再慢慢往里面填窗口管理、缓冲机制和合成路径。填到你自己能对着图讲出每个环节的日志和排查方法，就不再需要看教程了。
