1. 一张图背后的显示链路全景Android 显示链路这个话题我在刚接触 Framework 层的时候也觉得抽象。应用画了一帧怎么就跑到屏幕上了中间到底经过了几层为什么有时候会掉帧、撕裂、延迟这些问题如果不把整条链路捋清楚调优基本靠猜。这篇内容就是把我自己从踩坑到逐渐摸清链路的过程整理出来围绕 SurfaceFlinger、HWC、DRM 这几个核心角色把从 App 绘制到屏幕点亮的完整路径拆开讲。不管你是刚入行 Android 开发还是已经做了一段时间 Framework 或系统调优只要涉及画面显示、性能分析、多屏适配这条链路都是绕不开的基本功。先给一个整体印象。Android 的显示链路大致可以分成四段应用侧绘制、SurfaceFlinger 合成、HWC 硬件合成决策、DRM/KMS 驱动送显。每一段都有自己的缓冲区和同步机制任何一段卡住用户看到的就是掉帧或者卡顿。很多人调显示问题只盯着 App 的 onDraw其实真正的瓶颈往往在后面几段。理解这条链路你才能知道dumpsys SurfaceFlinger里那些数字到底在说什么才能判断一帧到底是 App 画慢了还是合成来不及还是送显环节出了问题。这篇文章我会按“整体设计思路 → 核心角色与数据流 → 实操抓取与验证 → 常见问题排查”的顺序展开尽量把每个环节的“为什么”讲清楚。文中涉及的命令和参数都是我在实际项目里反复用过的可以直接拿去复现。需要说明的是不同 Android 版本和芯片平台在细节上会有差异我会以通用主线为主遇到平台差异的地方会特别标注。2. 显示链路整体设计与分层思路2.1 为什么要分层从生产者到消费者的解耦Android 显示链路的设计核心其实是生产者-消费者模型。App 是生产者负责把 UI 画到一块缓冲区里屏幕是消费者负责把缓冲区的内容显示出来。中间如果让 App 直接操作屏幕会有几个致命问题多个 App 同时想画怎么办屏幕刷新率和 App 绘制速度不一致怎么办不同硬件屏幕的驱动差异谁来屏蔽所以 Android 在中间插入了一个合成层也就是 SurfaceFlinger再加上硬件合成器 HWC 和底层显示驱动 DRM/KMS。这样分层之后每一层只关心自己的职责App 只管画SurfaceFlinger 只管合HWC 决定用 GPU 还是专用硬件来合DRM 负责把最终画面送到显示控制器。层与层之间通过 BufferQueue 传递缓冲区通过 fence 做同步既解耦又高效。这种设计的好处是显而易见的。App 不需要知道屏幕是 60Hz 还是 120Hz也不需要知道底层是 MIPI DSI 还是 HDMI。它只需要在合适的时机把内容画好剩下的交给系统。代价是链路变长出问题时定位变复杂这也是为什么显示性能分析需要一套专门的方法论。2.2 双缓冲与三缓冲为什么需要多个 Buffer如果只有一块缓冲区App 正在画的时候屏幕就要读必然撕裂。所以至少需要双缓冲一块给 App 画back buffer一块给屏幕读front buffer。画完交换。但双缓冲在 App 绘制时间超过一个刷新周期时会出现 App 和屏幕互相等待的情况导致掉帧。三缓冲在此基础上再加一块让 App 在屏幕还在读上一帧的时候就能开始画下一帧减少等待。Android 从某个版本开始默认使用三缓冲Triple Buffering具体数量可以通过dumpsys SurfaceFlinger查看每个层的 buffer 状态。缓冲不是越多越好多了会增加延迟从触摸到显示的时间变长所以这是一个延迟和流畅度之间的权衡。游戏类应用通常更在意延迟系统 UI 更在意流畅这也是为什么不同场景下 buffer 策略会不一样。2.3 VSYNC 的角色把所有人的节奏对齐VSYNC 是显示链路里的节拍器。屏幕每刷新一次硬件产生一个 VSYNC 信号系统把这个信号分发给 App 和 SurfaceFlinger让它们在合适的时间点开始工作。App 收到 VSYNC 后开始绘制下一帧SurfaceFlinger 收到 VSYNC 后开始合成。这样所有人的节奏都和屏幕刷新对齐避免各画各的导致撕裂。VSYNC 的引入也带来了“错过一班车等下一班”的问题。如果 App 在一个 VSYNC 周期内没画完这一帧就赶不上本次合成只能等下一个周期用户感知就是掉了一帧。理解 VSYNC 分发机制是分析掉帧问题的前提。现在很多高刷屏还有可变刷新率VRRVSYNC 的节奏会动态调整链路会更复杂一些但基本模型不变。3. 核心角色与数据流拆解3.1 App 侧从 View 到 Surface 的绘制App 侧的绘制起点是 View 树的遍历。ViewRootImpl发起performTraversals依次执行 measure、layout、draw。draw 阶段会把内容画到一块由 Surface 提供的 Canvas 上。这块 Surface 背后就连着一个 BufferQueueApp 是生产者SurfaceFlinger 是消费者。这里有个容易混淆的点App 画的不是“屏幕”而是“自己窗口对应的那块缓冲区”。窗口的位置、大小、层级由 WindowManager 和 SurfaceFlinger 管理App 只负责内容。所以你会看到 App 的绘制区域和最终屏幕上的位置是两回事中间还有一层合成时的变换。绘制完成后App 通过dequeueBuffer拿到一块空闲 buffer画完queueBuffer还给 BufferQueue同时带上一个 fence 表示“这块 buffer 什么时候可以被读”。这个 fence 机制很关键它让 GPU 渲染和后续合成可以并行不用 CPU 傻等。3.2 SurfaceFlinger合成的大管家SurfaceFlinger 是 Android 显示系统的核心服务。它维护着所有层Layer的信息每个 Layer 对应一个 Surface。它的主要工作是在收到 VSYNC 后遍历所有可见 Layer决定怎么把它们合成到最终屏幕画面上。合成方式有两种GPU 合成和硬件合成。GPU 合成就是用 OpenGL ES 或 Vulkan 把所有 Layer 画到一张纹理上再送出去硬件合成是交给 HWC由显示控制器里的专用硬件直接叠加多个层。显然硬件合成更省电、更快但硬件能同时处理的层数有限超出部分只能回退到 GPU 合成这个回退叫 GPU fallback是性能分析里的高频词。SurfaceFlinger 还负责层的可见性计算、裁剪、变换、透明度处理等。你在dumpsys SurfaceFlinger里看到的每个 Layer 的可见区域、合成方式、buffer 数量都是它管理的结果。3.3 HWC硬件合成的决策者HWCHardware Composer是显示控制器抽象层。SurfaceFlinger 把当前所有 Layer 的信息交给 HWCHWC 根据硬件能力决定哪些层能由硬件直接合成哪些需要 GPU 先合好再交给它。这个决策过程叫 validate返回的结果里会标明每个层的合成方式。HWC 的存在是为了充分利用显示控制器的硬件叠加能力。比如视频层、UI 层、鼠标层很多显示控制器可以同时叠加好几层完全不需要 GPU 参与这样功耗低、延迟小。但如果层数太多、格式不支持、有复杂变换HWC 就会说“这个我搞不定”SurfaceFlinger 就得先用 GPU 合一部分。理解 HWC 的决策逻辑对优化显示功耗和性能非常重要。很多时候你发现 GPU 占用高不一定是 App 画得复杂而是 HWC 没接住导致 GPU fallback。3.4 DRM/KMS把画面送到屏幕的最后一步DRMDirect Rendering Manager和 KMSKernel Mode Setting是 Linux 内核里的显示子系统。HWC 最终会把合成好的画面通过 DRM 接口提交给显示控制器显示控制器再通过 MIPI DSI、HDMI、DP 等接口把画面送到屏幕。KMS 负责管理显示管线CRTC显示控制器、Encoder编码器、Connector物理接口、Plane图层。HWC 的硬件合成本质上就是在配置这些 Plane把不同的 buffer 分配到不同的 Plane 上由 CRTC 扫描输出。DRM 则提供了统一的 ioctl 接口让用户空间可以操作这些硬件资源。这一层离应用开发者最远但很多显示问题比如分辨率切换、多屏输出、HDR 处理最终都要落到这里。如果你做的是系统级开发或者显示驱动相关的工作这部分必须熟悉。3.5 数据流全景一帧的完整旅程把上面几个角色串起来一帧的旅程大致是这样的App 收到 VSYNC开始绘制画到 Surface 的 buffer 上。画完 queueBufferbuffer 进入 BufferQueue带上 fence。SurfaceFlinger 收到 VSYNC收集所有 Layer 的最新 buffer。SurfaceFlinger 把 Layer 信息交给 HWC 做 validate。HWC 决定合成方式能硬件合成的直接配置 Plane不能的让 GPU 先合。合成结果通过 DRM 提交给显示控制器。显示控制器在下一个 VSYNC 扫描输出到屏幕。整个过程里fence 负责同步VSYNC 负责节拍BufferQueue 负责缓冲。任何一个环节的延迟都会累积到最终的用户感知延迟里。4. 实操抓取与链路验证4.1 用 dumpsys SurfaceFlinger 看全局最常用的入口就是dumpsys SurfaceFlinger。这个命令输出很长但核心信息集中在几个部分Display 信息、Layer 列表、合成方式统计、buffer 状态。adb shell dumpsys SurfaceFlinger如果你只想看 Layer 列表可以用adb shell dumpsys SurfaceFlinger --list这个会列出当前所有 Layer 的名字。名字通常包含包名和窗口类型比如com.example.app/com.example.app.MainActivity。找到你关心的 Layer 后可以针对性地看它的详细信息。在完整输出里我一般重点看这几项Display 的刷新率和分辨率确认当前屏幕状态。每个 Layer 的 composition type是 DEVICE硬件合成还是 CLIENTGPU 合成。CLIENT 多了说明 GPU fallback 严重。Buffer 数量和历史看是否有 buffer 堆积堆积往往意味着消费端跟不上。Frame missed 统计直接反映掉帧情况。4.2 抓取单帧的合成信息想看某一帧具体怎么合的可以打开 SurfaceFlinger 的详细日志。不同版本命令略有差异通用做法是adb shell dumpsys SurfaceFlinger --latency LayerName这个命令会输出该 Layer 最近若干帧的时间戳包括 App 绘制完成时间、SurfaceFlinger 合成时间、屏幕显示时间。通过这三个时间戳你能算出一帧在链路各段的耗时判断瓶颈在哪。时间戳的含义大致是第一列是 App 的绘制时间第二列是 SurfaceFlinger 的合成时间第三列是实际显示时间。如果绘制到合成之间间隔很大说明 SurfaceFlinger 那边排队了如果合成到显示之间间隔大说明送显环节有问题。4.3 用 systrace/Perfetto 看时间线命令行输出是数字不够直观。要看时间线用 Perfetto新版本取代了 systrace。抓取显示相关的 traceadb shell perfetto -o /data/misc/perfetto-traces/trace.pftrace -t 10s \ sched freq idle am wm gfx view binder_driver hal dalvik camera input res抓完后用 Perfetto UI 打开能看到 SurfaceFlinger、HWC、App 各自的线程活动以及 VSYNC 信号。重点看 SurfaceFlinger 的合成线程是否在每个 VSYNC 周期都按时完成App 的绘制线程是否经常跨 VSYNC。我自己的习惯是先在 Perfetto 里定位掉帧的时间点再回到 dumpsys 看那个时刻的 Layer 状态两边对照基本能锁定问题环节。4.4 查看 HWC 的决策结果HWC 的决策结果在 SurfaceFlinger 的 dump 里能看到但更详细的信息需要看 vendor 提供的 HWC dump。通用做法是adb shell dumpsys SurfaceFlinger | grep -A 20 Composition或者直接看 HWC 的 service dump不同平台命令不同常见的是dumpsys vendor.hwcomposer之类。这里能看到每个 Layer 被分配到了哪个 Plane是硬件合成还是 GPU 合成。如果发现大量 Layer 是 CLIENT 合成就要分析原因是层数超了格式不支持还是有缩放、旋转等 HWC 不支持的变换这些信息对优化合成路径很关键。4.5 验证 DRM 侧状态DRM 侧的信息在/sys/kernel/debug/dri/下需要 root 或 debug 权限。可以看当前 CRTC 的配置、Plane 的分配、Connector 的状态。adb shell cat /sys/kernel/debug/dri/0/state这个输出会显示当前显示管线的完整状态包括每个 Plane 对应的 framebuffer、CRTC 的扫描输出参数等。做多屏或者分辨率相关调试时这个文件非常有用。需要注意的是不同平台的 DRM 实现有差异节点路径和输出格式可能不同。高通、MTK、展锐各有各的 vendor 扩展通用部分以标准 DRM 为准。5. 常见问题与排查技巧实录5.1 掉帧问题怎么定位掉帧是最常见的显示问题。排查思路是自顶向下先确认是不是 App 绘制慢再看是不是 SurfaceFlinger 合成慢最后看是不是送显环节卡。具体操作上先用 Perfetto 抓一段 trace看 App 的绘制线程是否在每个 VSYNC 周期内完成。如果 App 经常跨 VSYNC那就是 App 侧的问题去看 onDraw、layout 有没有耗时操作。如果 App 没问题但 SurfaceFlinger 合成线程经常超时那就是合成侧的问题看是不是 GPU fallback 太多。如果合成也正常但显示时间戳间隔不均匀那可能是 DRM 侧或者屏幕本身的问题。我踩过的一个坑是App 侧看起来每帧都按时完成但用户还是感觉卡。后来发现是 buffer 数量配置成了 2导致 App 和 SurfaceFlinger 互相等待。改成 3 之后就顺了。所以 buffer 数量这个参数值得专门确认一下。5.2 GPU fallback 过多怎么办GPU fallback 过多会显著增加功耗和延迟。判断方法是看 dump 里 CLIENT 合成的 Layer 数量。如果超过预期就要分析原因。常见原因有几个一是 Layer 数量超过了 HWC 支持的 Plane 数这个只能通过减少 Layer 或者合并 Layer 来解决二是 Layer 的格式 HWC 不支持比如某些 YUV 格式或者带 alpha 的特殊格式三是 Layer 有 HWC 不支持的变换比如任意角度的旋转、非整数缩放。解决思路能合并的 Layer 尽量合并比如把多个 UI 元素画到同一个 Surface 上格式尽量用 HWC 支持的常见的 RGBA8888 一般都没问题变换尽量用 HWC 支持的角度通常是 0/90/180/270 度。5.3 显示延迟大的排查显示延迟指的是从触摸到画面变化的时间。这个延迟由触摸采样、App 处理、绘制、合成、送显几段组成。要定位哪段占大头可以用带时间戳的 trace。一个实用的方法是在 App 里记录触摸事件的时间在 SurfaceFlinger 的 latency 输出里找到对应帧的显示时间两者相减就是端到端延迟。如果延迟主要花在 App 处理上就优化 App 逻辑如果花在合成上就看合成路径如果花在送显上可能是屏幕本身的响应时间或者 DRM 配置问题。高刷屏对降低延迟有帮助但前提是链路各段都能跟上。如果 App 还是按 60Hz 的节奏画高刷屏也发挥不出来。5.4 多屏场景的注意事项多屏场景下每个 Display 有自己的 SurfaceFlinger 合成上下文和 HWC 实例。主屏和副屏的刷新率可能不同VSYNC 也独立。这时候要注意 Layer 到底在哪个 Display 上合成以及跨 Display 的移动怎么处理。常见问题是副屏掉帧但主屏正常这通常是副屏的合成路径或者带宽受限。排查时要单独看副屏的 dump 和 trace不能只看主屏。另外多屏同时输出时DRM 侧的带宽分配也可能成为瓶颈特别是高分辨率高刷新率同时开的时候。5.5 常见问题速查表现象可能原因排查手段解决方向周期性掉帧VSYNC 错过、buffer 不足Perfetto 看 VSYNC 对齐增加 buffer、优化绘制耗时GPU 占用高HWC fallback 过多dumpsys 看 composition type减少 Layer、用支持格式显示延迟大链路某段耗时latency 时间戳对比定位瓶颈段针对性优化副屏异常副屏合成/带宽问题单独 dump 副屏检查副屏 HWC 和 DRM 配置画面撕裂同步机制失效看 fence 和 VSYNC检查 buffer 交换逻辑5.6 几个实操心得第一个心得不要一上来就抓全量 trace信息太多反而看不清。先明确要查什么问题再决定抓哪些 category。比如查掉帧就重点抓 gfx、view、sched查功耗就加 freq、idle。第二个心得dumpsys 的输出最好重定向到文件再慢慢看终端里刷屏根本看不过来。可以adb shell dumpsys SurfaceFlinger sf.txt然后拉回本地分析。第三个心得不同 Android 版本的 dump 格式会变命令参数也可能调整。遇到对不上的情况先确认版本再查对应版本的文档或者直接看源码里 dumpsys 的实现。第四个心得显示问题很多时候是配置问题而不是代码问题。比如 buffer 数量、刷新率策略、HWC 的使能开关这些配置项在不同产品上可能不一样。排查时先把配置确认一遍能省很多时间。6. 链路优化的一些延伸思考把显示链路摸清之后你会发现很多优化手段其实是围绕“减少环节”和“对齐节奏”展开的。减少环节就是尽量让 HWC 直接合成避免 GPU 介入对齐节奏就是让 App 绘制、SurfaceFlinger 合成、屏幕刷新都踩在同一个 VSYNC 节拍上。现在高刷和可变刷新率普及之后节奏对齐变得更动态。App 需要根据当前刷新率调整自己的绘制策略系统也要在流畅和功耗之间做平衡。这些都对显示链路的理解提出了更高要求。如果你做的是游戏或者视频类应用还可以关注一下低延迟模式、游戏模式下的合成策略调整。这些模式下系统会牺牲一些缓冲来换延迟链路的行为和普通模式不太一样。另外随着折叠屏、多屏设备的增多跨 Display 的合成和送显也成了新的课题。一个应用可能同时出现在多个屏幕上每个屏幕的刷新率和分辨率都不同链路怎么协调是值得深入研究的方向。我在实际项目里最大的体会是显示链路的每一个环节都有它存在的理由遇到问题时不要急着绕过某一层而是先理解它为什么这么设计。很多时候看似“多余”的一层恰恰是为了解决某个你还没遇到的兼容性或性能问题。把链路吃透调优才有方向不然就是碰运气。