4、HWC（Hardware Composer）核心概念：合成器角色、图层合成策略、Overlay与GPU合成、Present与Release流程

在Android显示系统中，HWC（Hardware Composer）是连接上层UI框架与底层显示硬件的关键枢纽。它并非简单的“显示驱动封装”，而是一个具备合成决策、硬件能力抽象和帧生命周期管理的核心模块。理解HWC的工作机制，是进行显示性能优化、功耗调优以及解决花屏、卡顿、延迟等问题的前提。本章将深入剖析HWC的合成器角色、图层合成策略、Overlay与GPU合成的选择逻辑，以及帧提交与释放的完整流程。

上图展示了HWC在Android显示体系中的核心位置。SurfaceFlinger负责收集所有应用和系统UI的图层（Layer），并将这些图层的元数据（如位置、尺寸、格式、变换）和缓冲区句柄传递给HWC。HWC则扮演“合成仲裁者”的角色，它根据底层硬件的实际能力（如Display Engine支持的Overlay平面数量、格式转换能力、缩放能力等）来决定每一帧的合成方案。这个决策过程直接影响帧延迟、功耗和内存带宽占用。

4.1 合成器角色：从“被动执行”到“主动决策”

核心原理

HWC在Android 8.0之后（HIDL接口）和Android 13之后（AIDL接口）的角色发生了显著变化。早期HWC仅作为SurfaceFlinger的“执行者”，SF自己完成所有合成，HWC只负责把最终帧送给显示器。现代HWC则拥有合成决策权：SF将图层列表（Layer Stack）提交给HWC，HWC通过validate方法返回一个合成计划（Composition Plan），告知SF哪些图层可以由硬件Overlay直接显示，哪些图层需要GPU合成到Client Target缓冲区中。

这种角色的转变带来了三大好处：

• 降低GPU负载：大部分简单场景（如视频播放、游戏画面）的图层可以直接由Display Engine的Overlay平面处理，GPU无需介入。
• 减少内存拷贝：Overlay合成是零拷贝的，而GPU合成需要将各图层内容渲染到一块新的缓冲区中。
• 提升能效：硬件Overlay的功耗远低于GPU渲染，尤其在60fps持续输出的场景下差异明显。

判断方法

在系统开发中，我们可以通过以下方式观察HWC的角色行为：

1. 使用dumpsys SurfaceFlinger查看当前帧的合成方式统计，关注GLES（GPU合成）与HWC（Overlay合成）的比例。
2. 通过systrace抓取帧渲染轨迹，观察HWC validate和HWC present的时间戳。
3. 在HAL层实现中，打印validateDisplay的返回值，确认每个图层的合成类型（DEVICE表示Overlay，CLIENT表示GPU合成）。

4.2 图层合成策略：Overlay与GPU的博弈

核心原理

HWC的合成策略本质上是一个资源分配与约束满足问题。硬件Overlay平面是有限的（通常4-8个），且每个平面有格式、缩放、旋转等限制。HWC需要决定哪些图层可以映射到Overlay平面，哪些必须交给GPU处理。典型的约束条件包括：

判断方法

HWC的决策逻辑通常遵循以下优先级：

1. 优先Overlay：对于不透明、无复杂变换、格式匹配的图层，优先分配Overlay平面。
2. 处理冲突：当Overlay平面不足时，将最“昂贵”的图层（如视频层）保留在Overlay上，将UI图层降级为GPU合成。
3. 格式转换：如果某个图层需要格式转换（如RGBA转YUV），且硬件不支持，则必须走GPU。
4. 客户端合成：当所有Overlay平面耗尽，或存在硬件无法处理的图层时，HWC要求SF将所有图层合成到Client Target缓冲区。

案例拆解：视频播放场景

假设一个典型的视频播放界面，包含三个图层：视频层（YUV格式，全屏）、状态栏层（半透明）、控制栏层（带阴影特效）。

• 初始现象：视频播放时帧率不稳定，功耗偏高。
• 分析过程：通过dumpsys发现视频层被标记为CLIENT，即GPU合成。原因可能是HWC实现未正确声明支持YUV Overlay。
• 操作步骤：检查HAL的getCapabilities返回值，确认HWC_OVERLAY_SUPPORTED标志；检查Display Engine驱动是否支持YUV420格式的Overlay平面。
• 结果对比：修复后，视频层走Overlay，GPU负载降低约30%，功耗下降15%，帧率稳定在60fps。
• 复盘经验：HWC的Overlay能力声明必须与实际硬件严格匹配，否则SF会做出错误的合成决策。

4.3 Overlay与GPU合成的协同工作流

核心原理

现代HWC实现中，Overlay和GPU合成并非互斥，而是可以混合使用。例如，一个图层栈中有5个图层，硬件只有4个Overlay平面，HWC可以选择将其中4个图层直接显示，而将第5个图层（如一个带有复杂模糊效果的弹窗）交给GPU合成到Client Target缓冲区，然后由Display Engine将Client Target作为另一个Overlay平面与其余图层混合。

这种混合模式的关键在于Client Target缓冲区的管理。SF会分配一块与屏幕尺寸相同的缓冲区，GPU将需要合成的图层渲染到该缓冲区，然后HWC将其视为一个特殊的Overlay图层。

操作流程

// HWC validate阶段伪代码
for each layer in layerStack:
    if (layer.canUseOverlay() && overlayPlanesAvailable()) {
        layer.compositionType = DEVICE;
        assignOverlayPlane(layer);
    } else {
        layer.compositionType = CLIENT;
        needsClientComposition = true;
    }
if (needsClientComposition) {
    // 通知SF需要GPU合成
    setClientTargetRequired(true);
}
// HWC present阶段
for each layer in layerStack:
    if (layer.compositionType == DEVICE) {
        displayEngine.setOverlayPlane(layer);
    }
if (needsClientComposition) {
    displayEngine.setClientTarget(clientTargetBuffer);
}
displayEngine.commit();

常见误区

4.4 Present与Release流程：帧生命周期的完整闭环

核心原理

每一帧从提交到显示，需要经历三个关键阶段：Validate（验证）、Present（提交）和Release（释放）。HWC通过这三个阶段管理帧缓冲区（BufferQueue）的生命周期，确保生产者（App）和消费者（Display）之间的同步。

• Validate：SF调用validateDisplay，HWC检查图层栈并返回合成计划。如果计划与上次相同，可以跳过后续的presentDisplay中的重配。
• Present：SF调用presentDisplay，HWC将Overlay平面配置写入Display Engine寄存器，并触发VSYNC同步的帧切换。
• Release：当Display Engine完成扫描后，HWC通过releaseDisplay回调通知SF哪些缓冲区可以归还给生产者复用。

判断方法

在调试帧卡顿时，需要关注以下时间点：

案例拆解：帧延迟问题排查

背景与约束：某设备在滑动列表时出现周期性卡顿，帧率从60fps掉到45fps。系统为Android 12，使用高通骁龙芯片。

初始现象：通过systrace发现HWC present阶段耗时波动大，有时达到8ms。

分析过程：进一步抓取kernel trace，发现Display Engine在每次present时都需要重新配置时钟频率，原因是HWC在validate阶段频繁改变Overlay平面数量（从4个变为3个再变回4个），导致驱动无法保持最优时钟状态。

实际操作：

1. 修改HWC实现，增加Overlay平面分配的“粘性”策略：如果图层栈变化不大，尽量保持原有Overlay分配。
2. 在驱动层增加时钟频率的“保持窗口”，避免频繁升降频。

结果对比：优化后，present耗时稳定在2ms以内，帧率恢复60fps，功耗降低8%。

复盘经验：HWC的决策不仅要考虑当前帧的图层，还要考虑帧与帧之间的连续性。频繁的Overlay重配是性能杀手。