2. Android显示系统架构：SurfaceFlinger、HWC、Display HAL 核心链路
好，咱们进入第二章。这一章我打算聊聊Android显示系统的核心链路。说实话，很多做应用开发的同事，甚至一些系统工程师，对这块的理解都比较模糊。你问他屏幕上的画面是怎么画出来的，他可能只知道「App画好图，系统显示出来」。但中间发生了什么？谁在调度？谁在合成？谁在跟硬件打交道？嗯，这里面的门道可不少。
我个人习惯把显示系统比作一条「流水线」。App是原材料供应商，SurfaceFlinger是总装车间，HWC是质检和打包部门，Display HAL就是那个把包裹送到你家门口的快递员。今天，我们就沿着这条流水线走一遍。
核心要点： 整个显示链路的核心目标只有一个——把多个App的图层（Layer）高效、流畅地合成一帧画面，并送到屏幕上。任何一环出问题，都会导致冻屏或黑屏。
2.1 SurfaceFlinger：显示系统的「大管家」
SurfaceFlinger，简称SF。它是Android显示系统的核心服务，运行在System进程里。它的工作说白了就两件事：接收图层和合成输出。
每个App在屏幕上显示的内容，其实都是一个或多个Surface。SurfaceFlinger会收集所有App提交的Surface，然后决定怎么把它们叠在一起。你想想看，状态栏、导航栏、微信聊天窗口、抖音视频，这些图层都是独立的。SF需要知道谁在上层，谁在下层，哪个区域需要更新。
我遇到过一个问题：某款手机在打开相机后，屏幕突然卡住不动了。后来定位发现，是相机App提交了一个超大分辨率的Surface，SF在合成时内存分配失败，导致整个合成流程卡死。这就是典型的SF层面的问题。
SF的工作流程大致如下：
- 监听Vsync信号（垂直同步信号）
- 收集所有可见Layer的Buffer
- 计算合成方案（是GPU合成还是HWC合成）
- 执行合成操作
- 将最终结果提交给显示硬件
个人经验： 调试冻屏问题时，我建议先看SF的dump信息。执行 adb shell dumpsys SurfaceFlinger，你能看到每个Layer的状态、Buffer队列深度、合成方式等关键信息。很多时候，问题就藏在某个Layer的「Pending」状态里。
2.2 HWC：硬件合成器，效率的关键
HWC，全称Hardware Composer。它是Android 4.0之后引入的硬件抽象层。为什么要搞个HWC？说白了，就是为了省电、提效。
早期的Android版本，所有图层合成都在GPU里做。GPU虽然灵活，但功耗高。而且有些简单的合成操作（比如两个图层叠加），用硬件模块来做更快更省电。HWC就是干这个的——它把一部分合成工作交给显示硬件（Display Controller）去完成。
HWC的工作模式有两种：
| 模式 | 说明 | 适用场景 |
|---|---|---|
| GLES合成 | 由SurfaceFlinger调用GPU进行合成 | 图层数量少、有特效（模糊、圆角）时 |
| HWC合成 | 由显示硬件直接合成多个图层 | 图层数量多、无特效、追求低功耗时 |
我记得有一次，客户反馈说播放视频时屏幕偶尔闪一下。查了很久，发现是HWC在GLES合成和HWC合成之间频繁切换。每次切换都会导致一帧的抖动。解决方案是锁定合成模式，或者在切换时做缓冲处理。
避坑指南： 我曾经遇到一个黑屏问题，原因是HWC返回了一个错误的合成方案。它告诉SF「我能合成这5个图层」，但实际上硬件只能处理4个。结果SF信了，直接提交给显示驱动，驱动直接崩溃。所以，HWC的capability上报一定要准确，否则就是灾难。
2.3 Display HAL：连接系统和硬件的桥梁
Display HAL是Android显示架构的最底层。它定义了系统如何与显示硬件（LCD屏、OLED屏、HDMI输出等）交互。HAL层封装了硬件的具体差异，对上层提供统一的接口。
核心接口包括：
open()/close()：打开/关闭显示设备setPowerMode()：设置屏幕电源状态（亮屏、灭屏、待机）setDisplayConfigs()：设置显示参数（分辨率、刷新率）presentDisplay()：提交一帧画面到屏幕
这里有个关键点：Display HAL的presentDisplay()调用必须是同步的。什么意思？就是系统把帧数据交给HAL，HAL必须保证这帧数据真正送到了屏幕上，才能返回。如果HAL实现有问题，提前返回了，系统以为画面已经显示，但实际上硬件还在处理上一帧，就会导致画面撕裂或者黑屏。
我调试过一个案例：某款低端手机在快速滑动列表时，屏幕底部会出现一条黑线。后来发现是Display HAL的presentDisplay()实现中，DMA传输没有等待完成就返回了。上层以为画面已经完整显示，实际上底部数据还没传完。
2.4 核心链路：一帧画面的完整旅程
好，我们把三个角色串起来，看看一帧画面从App到屏幕的完整旅程：
- App绘制： App通过Canvas或OpenGL绘制内容，提交到Surface的BufferQueue中。
- SF唤醒： Vsync信号到来，SurfaceFlinger被唤醒。它遍历所有Layer，检查哪些Layer有新的Buffer。
- 合成决策： SF调用HWC的
prepare()方法，询问HWC：「这些图层你能合成吗？」HWC返回一个合成方案。 - 执行合成： 对于HWC能处理的图层，直接交给硬件；不能处理的，SF用GPU合成到一个临时Buffer中。
- 提交显示： SF调用HWC的
set()方法，把最终结果提交给Display HAL。 - 硬件刷新： Display HAL把数据写入显示控制器的FIFO，屏幕在下一个Vsync到来时刷新显示。
关键路径： 整个流程必须在16.6ms（60Hz刷新率）内完成。任何一个环节超时，都会导致掉帧。如果连续掉帧，用户就会感觉到卡顿。如果某个环节彻底卡死，那就是冻屏或黑屏。
2.5 常见问题与排查思路
基于上面的链路，我总结了几类常见问题：
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 冻屏（画面卡住不动） | SF主线程卡死、BufferQueue满、HWC死锁 | 检查SF的dump、查看线程堆栈 |
| 黑屏（屏幕无显示） | Display HAL返回错误、电源管理异常、HWC崩溃 | 检查logcat中HWC和HAL的日志 |
| 画面撕裂 | Vsync同步失效、HWC合成时序错误 | 检查Vsync信号、HWC的present时序 |
| 闪屏 | 合成模式频繁切换、Layer属性变化 | 查看SF的合成策略日志 |
嗯，这里要特别提一下冻屏。冻屏和黑屏不一样，黑屏是完全没有画面，冻屏是画面停在某一帧不动了。我遇到过最诡异的一个冻屏问题：用户正常使用手机，突然屏幕就卡住了，但触摸还有反馈（能听到声音）。后来发现是SF在等待一个Layer的Buffer时，那个Layer的App进程被kill了，但BufferQueue没有正确清理，导致SF永远等不到新Buffer。解决方案是在App异常退出时，强制释放其占用的Buffer。
我的调试习惯： 遇到显示问题，我第一件事就是抓取 adb shell dumpsys SurfaceFlinger --latency 数据。这个命令会输出每一帧的提交时间、完成时间、掉帧情况。通过分析这些时间戳，你能快速定位是哪个环节拖了后腿。
好了，这一章我们走完了Android显示系统的核心链路。从SurfaceFlinger的调度，到HWC的硬件加速，再到Display HAL的硬件交互，每个环节都有自己的职责和坑。下一章，我们会深入冻屏问题的具体案例，看看这些理论知识怎么用到实战中。