1. 从一张图说起Android显示链路到底在解决什么问题很多人第一次接触Android显示这块脑子里是散的应用画了一帧怎么就跑到屏幕上了中间到底经过了几层为什么有时候会掉帧、撕裂、延迟dumpsys SurfaceFlinger打出来一大堆看不懂的东西也不知道从哪看起。我当年也是这么过来的。刚开始做Framework的时候觉得显示就是onDraw画完就完事了后来才发现从应用到屏幕中间有一条相当长的链路每一环都可能成为瓶颈。这篇文章就是想把这条链路用一张图讲清楚——不是那种教科书式的罗列而是让你看完之后脑子里能形成一条完整的数据流知道每一帧从哪来、到哪去、在哪可能卡住。Android显示链路简单说就是应用通过图形APISkia、OpenGL ES、Vulkan把内容渲染到图形缓冲区GraphicBuffer然后由SurfaceFlinger这个系统级合成器把多个图层合成最后通过HWCHardware Composer交给显示控制器经由DRMDirect Rendering Manager驱动送到物理屏幕。这条链路上有CPU、GPU、合成器、显示硬件四个角色任何一个环节出问题你看到的可能就是卡顿、撕裂或者延迟。这篇文章适合谁看如果你是刚接触Android Framework的开发者想搞明白一帧的旅程如果你是做性能优化、需要定位掉帧问题的工程师或者你是做车机、TV、平板这类定制系统的需要理解显示子系统怎么调——那这篇内容应该能帮你把整条链路串起来。我会尽量用大白话实际命令踩坑经验来讲不堆术语。提示本文涉及的dumpsys、/d/节点、perfetto等工具需要在userdebug或eng版本上使用user版本很多调试接口是关闭的这点先记住。2. 一帧的完整旅程从应用绘制到屏幕点亮2.1 应用侧UI线程和RenderThread的分工先说应用这边。你在onDraw里画的那些东西并不是直接画到屏幕上的。Android从5.0引入RenderThread之后绘制被拆成了两个线程UI线程负责构建DisplayList记录要画什么RenderThread负责把DisplayList真正提交给GPU渲染。为什么要拆因为UI线程还要处理输入事件、生命周期、业务逻辑如果绘制也压在它身上一旦有耗时操作整帧就卡住了。拆开之后UI线程只管描述RenderThread异步去执行这样即使UI线程偶尔忙一下渲染还能跟上。具体流程是这样的UI线程在Choreographer的回调里执行measure/layout/draw把绘制指令记录到RenderNode树里通过syncFrameState把渲染节点同步给RenderThreadRenderThread调用Skia或OpenGL ES把内容画到一块GraphicBuffer上画完之后这块Buffer通过BufferQueue交给SurfaceFlinger。这里有个关键概念叫BufferQueue它是生产者和消费者之间的桥梁。应用是生产者ProducerSurfaceFlinger是消费者Consumer。应用画好一帧就queueBufferSurfaceFlingeracquireBuffer拿走去合成。这个队列通常是三缓冲triple buffering也就是最多能缓存3帧这样应用和合成器可以并行工作不用互相等。2.2 SurfaceFlinger系统级的合成大师SurfaceFlinger是Android显示链路的核心。它的职责很明确把所有可见的Layer合成成一张最终的图交给显示硬件。每个Window应用窗口、状态栏、导航栏、壁纸等在SurfaceFlinger里都对应一个Layer。每个Layer有自己的BufferQueue、位置、大小、透明度、Z序等信息。SurfaceFlinger每收到一个VSync信号就会遍历所有Layer检查哪些有新的Buffer根据Z序、可见区域、透明度等决定怎么合成调用HWC或者GPU进行合成把合成结果提交给显示驱动。这里有个很重要的优化点SurfaceFlinger并不总是自己用GPU合成。如果硬件支持它会尽量把合成工作交给HWCHardware Composer因为HWC是显示控制器的一部分合成不消耗GPU资源也不占带宽功耗更低。只有当HWC处理不了比如图层太多、有特殊混合模式、有圆角/模糊等效果时才会回退到GPU合成Client Composition。你可以用这个命令看当前是哪种合成方式adb shell dumpsys SurfaceFlinger输出里会有一行类似Composition Display[0]的信息里面会列出每个Layer的合成类型Device表示HWC合成Client表示GPU合成。如果发现大量Layer是Client那就要注意了可能是HWC能力不足或者配置有问题。2.3 HWC与DRM最后一公里的硬件接力HWCHardware Composer是显示控制器里的硬件模块它负责把多个图层叠加成最终画面。不同厂商的HWC实现不一样但基本能力都包括图层叠加、缩放、旋转、色彩空间转换等。HWC之上是DRMDirect Rendering Manager这是Linux内核的显示子系统框架。DRM负责管理显示控制器、CRTC、Encoder、Connector这些硬件资源最终把画面输出到物理屏幕。Android通过hwcomposerHAL和DRM驱动交互把合成好的图层配置写入硬件寄存器等待VSync到来时切换。整个链路可以用一张简化的图来表示应用 (UI线程 RenderThread) ↓ 绘制到GraphicBuffer BufferQueue (生产者-消费者) ↓ queueBuffer / acquireBuffer SurfaceFlinger (Layer管理 合成决策) ↓ 选择HWC或GPU合成 HWC (硬件合成) / GPU (Client合成) ↓ 提交到DRM DRM/KMS (内核显示驱动) ↓ 扫描输出 物理屏幕这张图看着简单但每一层都有大量细节。比如BufferQueue的同步机制、SurfaceFlinger的VSync调度、HWC的Overlay限制、DRM的Plane分配等等。下面我挑几个最容易出问题、也最值得深挖的点展开讲。3. 合成路径的选择逻辑HWC什么时候会甩锅给GPU3.1 Overlay与GPU合成的本质区别HWC合成和GPU合成的区别不只是谁来做的问题而是功耗和带宽的问题。HWC合成是硬件直接叠加图层不需要把图层数据读到GPU里再写回去省掉了两次内存带宽消耗。GPU合成则要把所有图层的数据读进来混合之后再写出去带宽消耗大功耗也高。所以在移动设备上能走HWC就尽量走HWC。但HWC不是万能的它有硬件限制。常见的限制包括图层数量限制很多HWC只支持4-8个Overlay超过就得回退GPU缩放限制某些HWC不支持任意比例的缩放或者缩放质量有限格式限制不是所有像素格式都支持比如某些YUV格式可能不支持混合模式限制如果图层有特殊的混合模式如BlendModeHWC可能处理不了裁剪和旋转限制复杂的裁剪区域或旋转角度可能不支持。当HWC处理不了某个Layer时SurfaceFlinger会把这个Layer标记为Client合成也就是用GPU画到一张中间Buffer上然后再把这张Buffer作为一个Layer交给HWC。这就是所谓的GPU fallback。3.2 怎么判断当前合成路径是否健康最直接的方法还是看dumpsys SurfaceFlinger。我一般会关注这几个点adb shell dumpsys SurfaceFlinger | grep -A 20 Composition Display输出里会列出每个Layer的名字和合成类型。如果看到大量Client尤其是那些本来应该走HWC的普通应用图层那就有问题了。另一个命令是看HWC的能力adb shell dumpsys SurfaceFlinger | grep -i hwc不同平台输出不一样但一般能看到HWC支持的Overlay数量、支持的格式等。还有一个很实用的命令是dumpsys SurfaceFlinger --latency可以看某一层的帧延迟adb shell dumpsys SurfaceFlinger --latency LayerName它会输出一串时间戳分别是应用提交时间、SF开始合成时间、SF完成合成时间。通过这三个时间可以算出应用侧的延迟和合成侧的延迟。3.3 踩坑经验图层太多导致掉帧我之前遇到过一个案例某个车机项目界面上有导航、音乐卡片、状态栏、悬浮球、倒车影像预览等一堆图层结果发现帧率上不去GPU占用很高。用dumpsys SurfaceFlinger一看发现大部分图层都是Client合成HWC只接了2个Overlay。原因就是图层数量超过了HWC的Overlay上限。解决方案有两个方向一是减少图层数量比如把一些静态的、不常变的图层合并二是调整图层顺序和属性让HWC能接管更多图层。后来我们把状态栏和导航栏合并成一个Layer又把悬浮球改成在应用内绘制而不是独立WindowHWC接管的图层数上去了GPU占用降了将近30%。注意不是所有平台都允许你随意调整Layer。有些厂商的HWC实现比较挑食需要结合具体平台的文档和调试节点来看。4. 用dumpsys和perfetto把链路看穿4.1 dumpsys SurfaceFlinger的常用姿势dumpsys SurfaceFlinger是排查显示问题最常用的工具但输出很长直接看容易懵。我一般会配合grep和几个常用参数# 看合成统计 adb shell dumpsys SurfaceFlinger --latency LayerName # 看所有Layer的列表和属性 adb shell dumpsys SurfaceFlinger --list # 看合成类型统计 adb shell dumpsys SurfaceFlinger | grep -E Device|Client # 看VSync和刷新率信息 adb shell dumpsys SurfaceFlinger | grep -i vsync\|refresh--latency这个参数特别有用它会输出128个采样点的延迟数据。每一行有三个时间戳单位纳秒第一个是应用queueBuffer的时间第二个是SurfaceFlinger开始处理的时间第三个是SurfaceFlinger完成合成的时间。通过这三个值可以算出应用提交到SF开始处理的延迟、SF处理耗时、以及总的端到端延迟。如果发现某个值异常大就能定位到是哪一段出了问题。4.2 perfetto把整条链路的时间线画出来dumpsys看的是快照perfetto看的是时间线。如果你想搞清楚一帧从应用到屏幕到底花了多久、每一段耗时多少perfetto是最佳选择。抓取方法# 抓取10秒的显示相关trace adb 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打开可以看到详细的线程时间线。重点关注这几个TrackSurfaceFlinger看它的合成周期、VSync对齐情况RenderThread看应用的渲染耗时HWC看硬件合成的时间点VSYNC看VSync信号的分布。我一般会先看SurfaceFlinger的合成周期是否稳定。如果发现某些帧的合成时间明显偏长再去看那一帧对应的应用RenderThread在干什么是不是有耗时操作。4.3 一个真实的掉帧排查案例之前有个项目反馈滑动列表偶尔卡一下。我用perfetto抓了一段trace发现大部分帧都是16.6ms左右60fps但每隔十几帧就有一帧超过30ms。进一步看那一帧的RenderThread发现它在做一次TextureUpload也就是把一张Bitmap上传到GPU。再往上追发现是列表里某个Item在滑动时动态加载了一张大图而且没有做尺寸压缩直接原图上传。解决方案很简单在后台线程提前把图片decode并压缩到合适尺寸滑动时直接用小图。改完之后掉帧就消失了。这个案例说明一个问题显示链路上的问题根因往往不在显示本身而在应用侧的资源处理。所以排查的时候不能只盯着SurfaceFlinger要结合应用侧的trace一起看。5. 那些容易混淆的概念VSync、三重缓冲与帧延迟5.1 VSync到底同步了什么VSyncVertical Synchronization是显示器的垂直同步信号表示一帧画面已经扫描完成可以开始下一帧了。Android的整个显示链路都是围绕VSync来调度的。VSync的作用是避免撕裂。如果没有VSync应用可能在屏幕还在扫描上一帧的时候就更新了Buffer导致屏幕上半部分是旧帧、下半部分是新帧这就是撕裂。Android里有两个VSync硬件VSync和软件VSync。硬件VSync来自显示控制器软件VSync是SurfaceFlinger根据硬件VSync分发给应用的。应用通过Choreographer接收VSync然后在回调里开始下一帧的绘制。VSync的周期决定了刷新率。60Hz屏幕的VSync周期是16.67ms90Hz是11.11ms120Hz是8.33ms。如果应用一帧的处理时间超过了VSync周期就会掉帧。5.2 三重缓冲不是越多越好前面提到BufferQueue通常是三缓冲。为什么是三缓冲而不是双缓冲双缓冲的问题是应用在画第N1帧的时候SurfaceFlinger可能还在用第N帧合成如果应用画完了但SurfaceFlinger还没释放第N帧的Buffer应用就得等这就造成了背压。三缓冲多了一块Buffer应用可以提前画好一帧放在队列里不用等SurfaceFlinger。但三缓冲也有代价延迟增加。因为队列里可能积压了帧你看到的内容可能比实际晚一到两帧。对于游戏这种对延迟敏感的场景有时候会主动降到双缓冲来降低延迟。所以缓冲数量不是越多越好要在流畅度和延迟之间做权衡。这个权衡在不同场景下结论不一样需要结合具体需求来调。5.3 帧延迟的组成一帧从应用产生到屏幕显示延迟由几部分组成阶段典型耗时影响因素应用绘制2-8msUI复杂度、GPU性能BufferQueue排队0-16ms缓冲数量、合成节奏SurfaceFlinger合成2-6ms图层数量、合成方式HWC/DRM提交1-3ms硬件能力、Plane分配屏幕扫描输出0-16ms刷新率、扫描位置总延迟通常在30-60ms之间。如果要做低延迟优化比如云游戏、AR就要从每一段去抠。6. 定制系统里的显示链路车机、TV与多屏场景6.1 多屏异显的挑战车机和TV经常有多块屏幕而且刷新率、分辨率可能不一样。这对显示链路提出了额外要求每个Display有独立的SurfaceFlinger合成周期不同屏幕的VSync可能不同步SurfaceFlinger需要为每个Display单独调度HWC要支持多个Display不是所有HWC都支持多Display同时合成有些需要分时复用DRM要管理多个CRTC和Connector每个屏幕对应一组CRTC/Encoder/Connector资源分配要合理。在多屏场景下dumpsys SurfaceFlinger会列出多个Display每个Display有自己的合成统计。排查问题时要先确认是哪个Display出问题再看那个Display的Layer和合成路径。6.2 车机特有的显示需求车机对显示的要求和手机不太一样启动速度倒车影像、仪表盘要求上电后快速显示不能等Android完全启动功能安全仪表盘显示不能出错需要独立的显示通道和校验机制多区域显示一块屏幕可能分成多个区域分别显示不同内容。这些需求导致车机的显示链路往往在标准Android之上做了大量定制。比如有些方案会在kernel层做early display在Android启动前就先点亮屏幕显示倒车影像有些方案会用独立的MCU控制仪表显示Android只负责娱乐部分。如果你在做车机显示相关的工作建议先搞清楚项目的显示架构是纯Android控制还是有MCU参与是单Display还是多Display这些决定了你排查问题的思路。6.3 TV场景的刷新率切换TV场景经常需要根据视频内容切换刷新率比如24Hz的电影、60Hz的UI。刷新率切换涉及到VSync周期变化、SurfaceFlinger重新配置、HWC重新设置时序等一系列操作。切换过程中如果处理不好会出现黑屏、闪烁或者短暂卡顿。Android提供了setFrameRate接口应用可以请求特定的刷新率。但实际生效需要HWC和DRM的支持而且切换时机要把握好最好在内容切换的间隙做避免影响用户体验。7. 几个我踩过的坑和对应的排查思路7.1 黑屏问题从DRM往上查黑屏是最让人头疼的问题之一。我的排查思路是从下往上先看DRM层adb shell cat /d/dri/0/summary不同平台路径可能不同确认CRTC、Plane、Connector的状态再看HWCadb shell dumpsys SurfaceFlinger | grep -i hwc确认HWC是否正常工作再看SurfaceFlinger确认是否有Layer、合成是否正常最后看应用确认应用是否在正常绘制。这样一层层往上查能快速定位是哪一层出了问题。我遇到过好几次是DRM的Plane分配失败导致黑屏这种情况在dmesg里通常能看到相关报错。7.2 撕裂问题检查VSync和合成时机撕裂通常是VSync没有正确对齐导致的。排查步骤确认硬件VSync是否正常adb shell dumpsys SurfaceFlinger | grep -i vsync确认SurfaceFlinger的合成是否在VSync周期内完成检查HWC的提交时机是否正确。有些平台的HWC实现有问题会在VSync之外提交导致撕裂。这种情况可能需要更新HWC固件或者调整驱动配置。7.3 卡顿问题区分是应用侧还是合成侧卡顿的根因可能在应用侧也可能在合成侧。区分方法如果perfetto里看到RenderThread耗时很长那是应用侧问题如果RenderThread正常但SurfaceFlinger合成时间长那是合成侧问题如果两者都正常但帧率还是低那可能是VSync调度或者HWC的问题。我一般会先用dumpsys SurfaceFlinger --latency看端到端延迟如果延迟稳定但帧率低说明是周期性掉帧如果延迟波动大说明是偶发性卡顿。然后再用perfetto定位具体是哪一段。7.4 内存问题GraphicBuffer泄漏GraphicBuffer泄漏是显示链路里比较隐蔽的问题。表现是系统运行一段时间后内存持续增长最终OOM。排查方法adb shell dumpsys SurfaceFlinger | grep -i buffer看Buffer的总数和各Layer的Buffer数量。如果某个Layer的Buffer数量持续增长不释放那就有泄漏。常见原因是应用没有正确释放Buffer或者SurfaceFlinger的Layer没有及时销毁。这种情况需要结合应用的生命周期和SurfaceFlinger的Layer管理来排查。8. 把链路知识变成排查能力说了这么多核心其实就一句话Android显示链路是一条从应用到屏幕的数据流每一环都有明确的职责和可能的瓶颈。你脑子里有了这条链路排查问题时就能按图索骥而不是盲目试错。我自己的习惯是遇到显示问题先问三个问题问题出在哪一层是应用没画、SF没合成、HWC没提交还是DRM没输出这一层的输入输出是什么输入正常吗输出符合预期吗和正常情况比差异在哪是时间上的差异延迟、掉帧还是内容上的差异黑屏、花屏把这三个问题回答清楚大部分问题都能定位到。剩下的就是具体平台的细节了那需要结合平台的文档和调试节点来搞。最后分享一个我常用的命令组合基本能覆盖80%的显示排查场景# 一键抓取显示相关状态 adb shell dumpsys SurfaceFlinger sf.txt adb shell dumpsys display display.txt adb shell dumpsys window window.txt adb shell cat /d/dri/0/summary drm.txt 2/dev/null adb logcat -d | grep -iE surfaceflinger|hwc|drm log.txt把这几个文件拿到手大部分问题都能看出端倪。如果还不够再上perfetto抓trace。这套流程我在多个项目上用过效率比盲目试错高得多。显示这块内容很深一篇文章肯定讲不完。但只要你把这条主链路搞清楚了后面遇到具体问题再深入就不会迷失方向。