开始做Android图形性能优化之前，我有个建议：先别急着抓trace，别急着读Systrace的彩色条带，先花半天时间把Android图形系统架构的整体骨架刻在脑子里。原因很简单——你遇到的几乎所有卡顿、掉帧、花屏、功耗问题，归根结底都在讲同一件事：一条图像数据，在几个参与者之间怎么产生、怎么排队、怎么被消费。如果手里只有几个零散知识点，定位问题基本靠猜，优化结果往往是按下葫芦浮起瓢。这个图形专题系列，第一篇我就想把Android图形系统架构掰开揉碎讲清楚，从应用层到HAL层，每一层负责什么、边界在哪里、数据以什么形式流转，顺便把后面几篇要展开讲的内容做个地图。
这个内容适合三类人看：一是做Android系统开发、Framework定制的人，二是做应用层性能优化、想搞清楚卡顿根因的开发者，三是正准备啃Android源码但不知道该从哪下手的学习者。看完之后你至少能回答三个问题：一帧画面从App产生到屏幕显示，中间经过哪几个环节；每个环节的耗时上限在哪里；出了问题该去哪一层找证据。
1. 先建立全局坐标系：Android图形栈的分层模型
1.1 从"画"到"显"的四个关键角色
很多人提起Android图形系统，第一反应是SurfaceFlinger，但SurfaceFlinger只是其中一个环节。一条完整的图像流水线里，有四个角色缺一不可：
- 应用进程里的渲染线程：负责把View、Compose、SurfaceView的内容绘制成一张张位图，也就是“帧”。
- BufferQueue：帧数据的搬运通道，应用把画好的帧放进去，消费方从里面取走。
- SurfaceFlinger：系统核心合成器，把多个应用、多个窗口的图层按Z轴顺序合成为一帧最终画面。
- HWC（Hardware Composer）：硬件合成器抽象层，把合成结果交给显示控制器（Display Controller）最终输出到屏幕。
这个链路看起来简单，但每个角色都不是单线程干活，而且它们之间的连接方式决定了整个系统的性能边界。App侧的渲染线程通过CPU（Skia/Canvas）或GPU（OpenGL ES/Vulkan）生成内容，生成的帧不是直接进屏幕，而是先放进一块共享内存区域，等SurfaceFlinger来取。SurfaceFlinger拿到所有窗口的帧之后，经过合成（Composition）再交给HWC，HWC负责把像素真正推送到物理显示接口上。
理解这个模型，最关键的一点是：App负责“逐层绘制”，SurfaceFlinger负责“多层叠加”，HWC负责“最终输出”。三者各管一段，谁也替代不了谁。很多性能问题就出在把这三者的职责搞混了——比如有人把界面卡顿归咎于SurfaceFlinger，但实际上App侧根本没有按期把帧交上来；有人以为加大HWC能力就能让所有页面变流畅，但其实大量小图层在App侧就已经拖慢了渲染线程。
1.2 源码里对应的关键目录
架构不是空中楼阁，它最终落在代码上。我建议读者把下面几个目录在本地AOSP里标上书签，后续篇幅会频繁提到：
| 目录 | 对应模块 | 作用 |
|---|---|---|
| frameworks/native/libs/gui | BufferQueue、Surface、SurfaceControl | 生产-消费模型的核心实现 |
| frameworks/native/services/surfaceflinger | SurfaceFlinger服务 | 图层管理、合成调度、VSYNC |
| frameworks/native/services/surfaceflinger/RenderEngine | GPU合成引擎 | 用GPU完成客户端合成 |
| hardware/interfaces/graphics/composer | HWC接口 | 硬件合成抽象层 |
| frameworks/base/core/java/android/view | ViewRootImpl、Surface | 应用侧Java层入口 |
| frameworks/native/libs/renderengine | RenderEngine抽象 | 渲染引擎封装 |
这几个目录你顺着读一遍，基本就能在代码层面把所有角色对号入座。实际写代码的时候，你会发现很多关键类名在Java层和Native层各有一份，比如Surface在Java层是android.view.Surface，Native层是android::Surface，它们通过JNI联系但职责不同。Java层Surface主要给App提供绘制接口，Native层的Surface才是BufferQueue的生产端门面。
2. BufferQueue：贯穿图形系统的那条“传送带”
2.1 生产者与消费者：图像数据的交接仪式
BufferQueue是整个Android图形系统里最容易被忽视、但最值得细看的部分。我习惯把它比作一条传送带，App把画好的帧放到一个槽位上，SurfaceFlinger从槽位上取走，取完之后槽位又空出来给App继续画。这个“放-取-还”的循环，几乎构成了Android图形系统的全部节奏。
从API层面看，生产者走的是dequeueBuffer（申请空槽）→ 写入像素 → queueBuffer（上架）这条路，消费者走的是acquireBuffer（取走）→ 处理/合成 → releaseBuffer（归还）这条路。缓冲区在任一时刻处于四种状态之一：
| 状态 | 含义 | 谁拥有 |
|---|---|---|
| FREE | 空闲，可以被生产者申请 | 队列 |
| DEQUEUED | 生产者已申请，正在画 | 生产者 |
| QUEUED | 已画完，等待消费者 | 队列/消费者 |
| ACQUIRED | 消费者已取走 | 消费者 |
这四种状态的流转设计得很巧妙，它保证了同一个缓冲区不会同时被生产者和消费者读写。你实际调优时遇到的“掉帧”“纹理等待”，本质上就是某个状态卡住的时间超出了预算。
值得注意的是，现代Android（Android 10以后的BLAST架构）里，BufferQueue的回调机制已经发生了改变，不再通过传统的listener通知SurfaceFlinger“有新帧来了”，而是App直接通过Transaction机制提交Buffer，再由SurfaceFlinger按VSYNC节奏统一处理。这个细节在后面讲调度时还会展开，但核心的生产-消费模型没有变。
2.2 为什么缓冲区数量是2到3个而不是更多
很多初学者会问：既然排队会等，那把缓冲区做多一点不就不等了？这就是典型的“只看到延迟，没看到功耗”。缓冲区数量直接决定了“App最多能提前画多少帧”，缓冲区越多，画面延迟越高，系统为了维持流畅需要付出的调度成本也越高。Android默认在绝大多数场景使用双缓冲或三缓冲，这是一个经过权衡的折中。
用一组数字来说明：假设屏幕是60Hz，每帧预算16.6ms。双缓冲情况下，App绘制完一帧后可能没有空槽，必须等到SurfaceFlinger把上一帧合成完并归还缓冲区才能继续画，如果绘制耗时超过16.6ms，就会立刻丢掉一个VSYNC周期。三缓冲给App多了一个“提前画”的槽位，允许某一帧短时间超出预算，让系统靠队列消化波动。
这里需要澄清一个常见误区：三缓冲不是提升帧率的开关，而是“用多一个缓冲区的内存，换取绘制耗时抖动时的容错能力”。你开启三缓冲之后，从dumpsys SurfaceFlinger里看到的总Buffer数可能是3个甚至更多，但实际每一帧的延迟反而可能增加——因为App提前画出来的帧是排着队等待合成的。我见过不少团队一遇到卡顿就调大BufferQueue的maxBufferCount，结果掉帧率没降，触摸延迟却肉眼可见地变高了。
在Android 16上，这套BufferQueue机制依然是图形栈的地基，只是上层做了更多异步化处理。比如BLASTBufferQueue把生产者和SurfaceFlinger的交互进一步解耦，让App侧提交帧的路径更短。这些优化都是在不动地基的前提下把砖块砌得更薄。
3. SurfaceFlinger的合成策略：它究竟在忙什么
3.1 合成（Composition）不是渲染（Rendering）
我经常被问到同一个问题：“SurfaceFlinger是不是负责把所有View画出来？”答案是：不。App侧的View绘制、Canvas绘制、OpenGL/Vulkan绘制才是真正的渲染，SurfaceFlinger做的事情叫合成——它把多个已经画好的图层按照Z轴顺序、透明度、裁剪区域叠成一张最终画面。打个比方，App负责把食材做成几盘菜，SurfaceFlinger负责把它们摆到一张桌子上。
SurfaceFlinger的合成路径有两种：一种是客户端合成（Client Composition），也就是它自己调用GPU（RenderEngine）把多个图层画到一个目标缓冲区里；另一种是设备合成（Device Composition），也就是把图层列表直接交给HWC，让显示硬件自己完成叠加。实际处理时往往是混合的：HWC能处理的图层走硬件，不能处理的图层先由GPU合成到一个图层上，再把结果交给HWC。
合成的开销和图层数强相关。半透明图层、带圆角裁剪的图层、带阴影的图层，都会让GPU合成时的片元计算量成倍上升。你在日常开发中经常会遇到一个现象：某个页面上弹出了一个带大范围阴影的悬浮窗，整机帧率立刻下降，原因就是SurfaceFlinger本来可以走设备合成的图层组合被打乱了，被迫退回GPU合成。
3.2 VSYNC调度：App与SurfaceFlinger的握手协议
合成不能想什么时候做就什么时候做，否则会出现画面撕裂——屏幕上半部分显示新帧、下半部分还在显示旧帧。Android通过VSYNC信号来同步整条流水线，每个硬件VSYNC周期有两个派生信号：VSYNC-App和VSYNC-SF。前者驱动App的Choreographer回调，告诉应用“你可以开始画下一帧了”；后者驱动SurfaceFlinger，告诉合成器“现在可以把已提交的帧合成了”。
Android 16时期，这套双VSYNC模型仍然存在，但细节上做了不少演进，比如支持可变刷新率（VRR）面板时，系统会动态调整VSYNC频率，而不是死板地锁在60Hz或120Hz。对开发者而言，理解VSYNC的关键不在于记住信号怎么生成，而在于明白“掉帧的真实定义”：一帧画面没有在预定的VSYNC周期内被App绘制完成并提交给SF，或者SF没能在下一个周期前完成合成，都会导致该帧被跳过或重复显示。
很多人看Systrace时有一个误区：看到SF的合成时间只有2ms，就认为SF很快，然后去质疑App侧。实际上，SF只能消费App提交的帧，如果App在VSYNC到来时根本没有新帧可合成，SF就会用旧帧再撑一个周期，在trace上表现为一个很短的合成段+一个很宽的空白，真正的瓶颈在App侧。反过来，如果App每帧都准点提交，但SF合成时间飙到10ms以上，这时候才应该考虑是图层数太多还是HWC没有接管。
3.3 SurfaceFlinger的Transaction机制与帧ID
Android 10的BLAST改造之后，SurfaceFlinger接收的不再是简单的“新缓冲区通知”，而是一整套Transaction状态。App端通过SurfaceControl.Transaction来设置图层的位置、大小、透明度、裁剪区域、Buffer等属性，SF按帧序列号（FrameNumber）统一应用这些变更。这个机制让合成变得更加原子化，减少中间状态的暴露。
正是这个变化，让现代Android能做到“等待下一个VSYNC统一提交并应用所有窗口的变更”，避免了多个App在不同时间点提交图层属性变化导致的闪烁和错乱。你在dumpsys SurfaceFlinger里看到的大量Transaction信息，就是这个机制的状态快照。做系统级调试时，学会读这些信息比猜代码路径有用得多。
4. HWC硬件合成：省电与性能的真正胜负手
4.1 HWC不是什么“万能显卡”
HWC是hardware/interfaces/graphics/composer里定义的一套HAL接口，它向上对SurfaceFlinger暴露能力，向下调用显示控制器的Overlay引擎。这里必须强调：HWC不是GPU，不负责把3D场景画出来，它的核心能力是“把多个图层在显示硬件级别直接叠加”。显示控制器通常有几个Overlay Plane，每个Plane可以接收一个独立图层，硬件可以把这些图层按Z序叠加后直接输出到屏幕，整个过程不需要GPU参与，也不需要把多个图层先画到一张中间纹理上。
这种“硬件直接叠”的方式优势很明显：省电、低延迟、CPU/GPU占用几乎为零。视频播放、游戏画面、相机预览这些场景之所以流畅且耗电低，就是因为走的是HWC设备合成。你可以把HWC想象成会议室里的矩阵切换器，几路信号直接在输出端叠加，中间不经过任何转码。
4.2 合成决策：哪些层走硬件，哪些层走GPU
SurfaceFlinger每帧都要向HWC提交一个候选图层列表，HWC反馈“这些层我能直接叠，那些层我搞不定”。搞不定的层会被标为Client Layer，由SF用RenderEngine（GPU）先合成到一个专门的client target缓冲里，再将这个缓冲作为一层交给HWC。这个决策过程每一帧都在进行，受很多因素影响：
- 图层数量：HWC的Overlay Plane数量是固定的（常见是2到4个），超过上限的图层只能合并成client层。
- 图层格式：某些硬件不支持任意格式的图层做Overlay，比如带硬件旋转、带特殊压缩格式的层。
- 显示区域重叠/半透明：HWC处理不了复杂的混合（blend）需求，Alpha混合容易整层退回GPU。
- 帧缓冲约束：比如HDR、宽色域、局部刷新（DRM）等能力不支持时也会回退。
列一个实际场景，你就能直观感受到这个决策的破坏力：一个全屏VideoView播放视频（1个视频层）加上状态栏、导航栏（2个系统层），如果HWC有3个Plane，正好全部设备合成。这时候你突然在屏幕上弹了个半透明悬浮窗，图层变成4个，Plane不够用了。SurfaceFlinger可能被迫把“状态栏+悬浮窗+导航栏”三个层合成成一层，GPU合成耗时从0.5ms变成2ms，整机流畅度立刻受牵连。所以，系统优化时“图层管理”非常重要，一些桌面团队专门做“图层合并优化”，把多个小组件合并到一个独立的Surface上，就是为了降低SF的合成压力。
HWC接口发展到Composer 3.0以后，还加入了更多能力协商和性能提示机制，比如DisplayCapabilities、PerFrameMetadata等。Android 16的图形适配中，厂商需要重点关注的还是自家的Plane数量和混用规则，这直接影响整机的场景化功耗表现。
5. Android 16时代这套架构的演进方向
5.1 从OpenGL ES到Vulkan/ANGLE的结构性迁移
讨论Android 16的图形架构，绕不开一个问题：OpenGL ES正在被“移出”主舞台。Android已经将ANGLE（Almost Native Graphics Layer Engine）作为OpenGL ES在部分设备上的默认实现，ANGLE会把OpenGL ES的API调用翻译成Vulkan来执行。这意味着，即使应用还在用OpenGL ES写渲染代码，底层驱动实际执行的很可能是Vulkan。
这个变化对架构的影响很深远。Vulkan是一个显式控制GPU的API，驱动承担的逻辑更少、应用承担的逻辑更多，所以在老旧的OpenGL ES驱动上表现不稳定的场景，换到ANGLE+Vulkan之后往往更一致。但这也带来新的兼容问题：Shader的精度差异、同步行为不同、资源绑定方式不同，都可能让原本“能用”的GL代码出现视觉差异。我在实际项目中就遇到过某个App开启ANGLE后文字描边发虚的情况，最终定位到是特定GPU驱动对shader中mediump精度的处理方式与GLES原生效能不同。
Android图形栈之所以坚定走向Vulkan，根本原因是为了减少驱动负担、提高跨设备一致性。这个迁移对系统开发者来说，意味着排查渲染问题时的工具链要跟着变：Adreno工具、Mali Offline Compiler这些针对厂商驱动的调试方式，要逐步让位于更通用的Vulkan层检查。
5.2 刷新率、帧预测与HDR合成的新变量
早在Android 11就开始支持可变刷新率（VRR），Android 16上显示系统对这个能力的抽象更成熟了。当屏幕支持48Hz到120Hz的动态切换时，VSYNC不再是固定频率，SF需要依据当前场景的内容移动速度来决定“下一帧用多高的刷新率输出”。这个决策涉及功耗和流畅度的权衡，算法通常放在显示系统或厂商的Display HAL里。
另一个值得关注的演进是帧预测（Frame Prediction）。在120Hz屏幕上，如果App只按60FPS生成内容，显示系统可以通过“智能预测”在两帧之间插入一帧预测画面，从而把视觉流畅度提升到接近120FPS的观感。这个技术的难点在于预测的准确性——插错了就会产生鬼影。目前这项能力更偏向系统级优化，但未来开放给应用接口后，游戏和视频类应用可以直接受益。
HDR合成方面，现代Android要求合成器能够处理SDR和HDR图层混叠的场景：同一个屏幕上，普通界面是SDR亮度，视频窗口是HDR亮度，合成器必须对不同亮度域的图层做正确处理，通常涉及色调映射（Tone Mapping）和亮度调节。Android 16在这一块的架构没有推翻重来，但HWC对HDR元数据的透传能力、SF对混合亮度域的处理逻辑都在持续细化。这类问题普通应用开发者感知不强，却是厂商适配HDR显示时必须过的关卡。
6. 拿着架构图去定位问题的实战思路
6.1 我排查图形问题的固定顺序
架构是理论，落到实际还得靠工具。这些年我处理图形性能问题时，基本遵循一个从“产出端”到“消费端”的顺序：
- 先确认App侧是否按VSYNC周期产出帧：执行
adb shell dumpsys gfxinfo <package>，看Total frames rendered、Janky frames、50th percentile这些指标。如果App卡顿明显，去systrace里看Choreographer回调DoFrame有没有超时、draw/measure有没有卡在特定方法上。 - 再确认SF侧是否按时完成合成：
adb shell dumpsys SurfaceFlinger --latency可以看到每个Surface的帧时间戳，如果App侧每帧都准点，但SF侧出现FrameSpacing波动，说明问题在合成侧。 - 最后看HWC的参与度：
adb shell dumpsys SurfaceFlinger --list和--layer可以看到每个图层的合成状态，重点看是Device还是Client Composition。如果预期走设备合成的场景大面积退回客户端合成，说明图层结构或者HWC兼容性出了问题。
这套顺序有一个核心逻辑：“谁该为这一帧的延迟负责，从数据流的上游开始找”。很多新手习惯直接打开systrace全局搜索，看到什么红就点哪里，这样容易把App侧的慢和SF侧的慢混在一起。
下面这个表是我自己整理的高频命令和用途，读者可以直接存下来：
| 命令 | 关键信息 | 适合场景 |
|---|---|---|
| dumpsys gfxinfo | 帧耗时、掉帧统计、jank数据 | 应用渲染性能 |
| dumpsys SurfaceFlinger --latency | Surface帧时间戳、间隔 | SF合成节奏 |
| dumpsys SurfaceFlinger --layer | 图层属性、合成方式 | 图层结构分析 |
| dumpsys SurfaceFlinger --list | 当前所有Surface | 查看可见窗口/图层 |
| dumpsys display | Display状态、刷新率模式 | 刷新率/VRR问题 |
| adb shell screenrecord --bugreport | 录屏+元数据 | 复现花屏/闪烁问题 |
6.2 架构图之外的三个实操忠告
第一个忠告：不要只盯着SurfaceFlinger找卡顿。我接手过一个项目，现象是桌面滑动卡顿，初步抓systrace发现SF合成时间偏高，于是一群人在SF的合成算法里找了一周。后来我改了排查思路，先看App侧提交帧的时间戳，发现桌面的Launcher进程在特定场景下会突然出现一个90ms的绘制长帧，而SF只是被迫把一个晚到的帧合成了。问题根源在Launcher的一个布局计算上，跟SF一点关系都没有。
第二个忠告：图层数量是你最值得优化的性能指标。不管HWC有多强，每多一个图层就多一分合成压力，尤其是在有半透明效果、圆角裁剪、阴影的场景。应用开发时，能合并的Surface尽量合并，能用ViewStub延后创建的Surface不要提前创建；系统开发时，悬浮窗、Toast、权限弹窗这类临时图层，用完之后必须及时释放。我见过某个ROM的录屏功能因为持有一个全屏高分辨率Surface不被释放，导致后续所有App的合成都多了一个高开销图层，整机功耗直接上去。
第三个忠告：读dumpsys报告时，先关心“变化量”，不要只看绝对值。SurfaceFlinger的dumpsys输出非常庞大，动辄几千行。有经验的人不会逐行读，而是先在交互正常和异常时各抓一份，用diff找出变化的图层、变化的合成方式、变化的帧间隔。比如某次升级后出现花屏，对比两份dumpsys很可能会发现某个图层的transform从0变成了某个旋转值，这通常意味着App侧SurfaceControl的几何变换设置出了问题。这种“差分定位法”比在源码里靠猜高效得多。
说实话，Android图形系统这套架构从BufferQueue到SurfaceFlinger再到HWC，核心骨架已经有很多年没有根本性推翻了。它就像一栋老房子，每一代Android都在里面改水电、换门窗，但承重墙一直没动过。正因为如此，搞懂这套架构模型的投入产出比非常高——你在这里花的时间，在未来很长一段时间里都能用上。这篇文章给的是一张全景地图，后面几篇我打算沿着这条链路往深处走，逐个环节展开讲：BufferQueue的深度调优、SF的事务处理模型、HWC的合成决策算法，这些都是实操中真正会踩坑的地方。先把地图记牢，我们一步一步来。
