1、显示系统全景图：Android显示架构演进、SurfaceFlinger核心职责、HWC与GPU的分工、显示流水线概览
各位同学，咱们今天聊聊Android显示系统的全貌。
说实话，我刚入行那会儿，面对SurfaceFlinger、HWC、GPU这些概念，也是一头雾水。后来在几个项目中踩了坑，才慢慢理清了脉络。今天我就把这些经验分享给你。
1.1 Android显示架构的演进
Android的显示架构，说白了就是一条不断优化的路。
早期版本（Android 1.x-4.x）用的是单缓冲+直接渲染模式。那时候屏幕小、分辨率低，问题不大。但到了高清屏时代，这种方案就扛不住了——画面撕裂、掉帧成了家常便饭。
我记得在Android 4.4时代，Google引入了Triple Buffer机制。嗯，这里要注意，不是简单的三缓冲，而是配合了VSync信号同步。我曾在某款平板项目上，因为没处理好VSync对齐，导致UI滑动时总感觉“肉肉的”，后来才发现是Buffer切换时机不对。
到了Android 8.0以后，架构基本稳定下来：
- SurfaceFlinger作为核心合成引擎
- HWC（Hardware Composer）负责硬件加速合成
- GPU处理复杂渲染任务
- BufferQueue管理图形缓冲区流转
你想想看，这套架构已经用了快十年了，说明它的设计确实经得起考验。
1.2 SurfaceFlinger的核心职责
SurfaceFlinger是显示系统的“大管家”。它的工作，我总结为三件事：
- 接收图层：从各个App接收Surface数据
- 合成图层：决定哪些图层用GPU合成，哪些交给HWC
- 送显输出：把最终画面送到Display设备
这里有个关键点——SurfaceFlinger不直接渲染。它只负责“调度”和“合成决策”。真正的渲染工作，要么交给GPU，要么交给HWC。
核心流程：App绘制 → BufferQueue传递 → SurfaceFlinger合成 → HWC/GPU处理 → Display输出
我在做某款手机项目时，遇到过SurfaceFlinger线程卡死的问题。排查下来，是因为某个App频繁提交超大纹理，导致BufferQueue溢出。后来我们限制了单次提交的纹理大小上限，问题就解决了。
1.3 HWC与GPU的分工
很多人搞不清HWC和GPU到底谁干什么。我打个比方：
- GPU：像是一个全能画师，什么复杂的特效都能画，但速度相对慢
- HWC：像是一个复印机，只能做简单的叠加、裁剪，但速度极快
实际工作中，SurfaceFlinger会这样分配：
| 任务类型 | 处理单元 | 典型场景 |
|---|---|---|
| 简单图层叠加（2-3层） | HWC | 桌面、设置界面 |
| 复杂特效（模糊、旋转） | GPU | 游戏、视频编辑 |
| 混合模式（透明、遮罩） | GPU | 弹窗、动画 |
| 纯色背景、静态图层 | HWC | 状态栏、壁纸 |
我曾经在一个项目中，发现GPU负载过高导致发热严重。后来通过调整HWC的合成策略，把一些简单图层交给HWC处理，GPU负载降了30%，温度也下来了。
避坑指南：HWC不是万能的。它支持的图层数量有限（通常4-8层），超过限制的图层会自动回退到GPU合成。我曾经因为没注意这个限制，导致某款低端机上UI卡顿严重。
1.4 显示流水线概览
整个显示流水线，我习惯把它分成四个阶段：
- 应用绘制阶段：App通过Canvas或OpenGL绘制内容，提交到BufferQueue
- 合成决策阶段：SurfaceFlinger收集所有图层，决定合成方案
- 硬件处理阶段：HWC或GPU执行实际的合成操作
- 输出显示阶段：合成后的画面通过Display接口输出到屏幕
这里有个容易忽略的点——VSync信号。整个流水线都是靠VSync来同步的。如果VSync不稳定，画面就会出现抖动或撕裂。
我记得在调试某款折叠屏时，因为屏幕刷新率切换导致VSync信号紊乱，画面一直闪烁。后来我们在驱动层加了VSync信号过滤，才解决了问题。
注意：显示流水线的瓶颈往往不在渲染速度，而在Buffer传递和同步机制上。优化时优先检查BufferQueue的深度和VSync的稳定性。
好了，这一章的内容就到这里。显示系统全景图就像一张地图，有了它，后面我们深入每个模块时就不会迷路了。