Android HWC 硬件合成退化：成因分析、排查方法与防治策略

1. 从一个掉帧现场说起：HWC 到底在画面合成的哪一环

如果你做过 Android 系统性能优化，大概率遇到过这种场景：App 本身逻辑不重，GPU 占用也不高，但滑动列表就是有规律地掉帧，用dumpsys SurfaceFlinger一看，合成路径里出现了大量 GPU Client 合成，而 HWC 合成几乎没怎么干活。这时候问题往往不在应用层，而在HWC（Hardware Composer，硬件合成器）这一层。

先把概念摆清楚。Android 的显示合成链路大致是这样：应用通过 Surface 提交图层（Layer），SurfaceFlinger 负责收集、排序、决定每个图层怎么合成，最终把结果送到显示设备。合成这件事有两种做法，一种是让 GPU 把所有图层画到一张 buffer 上，这叫GPU Client 合成（也叫 GLES 合成）；另一种是把图层直接交给显示控制器硬件去叠加，这叫HWC 合成（硬件合成、Overlay 合成）。HWC 合成的好处很直接：不占 GPU、不占带宽、功耗低、延迟小。GPU Client 合成则是"兜底方案"，一旦 HWC 说"这几个图层我合不了"，SurfaceFlinger 就退回 GPU 去画。

所谓HWC 退化，指的就是本该由 HWC 硬件合成的图层，因为各种原因被迫回退到 GPU Client 合成。退化本身不是 bug，它是合成框架的正常兜底机制，但频繁退化就是性能问题了：GPU 负载上升、内存带宽被吃掉、功耗变高、掉帧概率变大。所以"防治"的核心不是消灭退化，而是让退化发生在该发生的时候，别在滑动、视频播放、游戏这些关键场景里乱退化。

这篇内容适合谁看？做 Android 系统开发、Framework/显示子系统、性能优化的工程师，以及被掉帧和功耗问题折磨的 ROM 开发者。我会从 HWC 的判定逻辑讲起，把退化的常见成因、排查手段、防治策略一条条拆开，尽量给到能直接上手复现的操作。需要说明的是，不同 SoC 平台（高通、联发科、展锐等）的 HWC 实现差异很大，下面涉及的参数和命令以通用 AOSP 逻辑为主，具体平台需要对照厂商文档做适配，这部分我会明确标注。

2. HWC 的判定逻辑：它凭什么拒绝一个图层

要治退化，先得知道 HWC 在什么情况下会"拒收"图层。HWC 不是随便就能合成任意图层的，它有一堆硬性约束，任何一个不满足，这个图层就得走 GPU。理解这些约束，是后面所有排查和优化的基础。

2.1 图层数量与硬件叠加层上限

最直观的一条：显示控制器能同时叠加的图层数量是有限的。早期设备可能只有 2 到 4 个 overlay 通道，现在主流平台能到 8 个甚至更多，但这个上限始终存在。当一帧里的图层数超过硬件通道数，多出来的图层就必须由 GPU 合成。

这里有个容易被忽略的点：图层数量不等于可见 Surface 数量。SurfaceFlinger 在送 HWC 之前会做一轮预处理，比如把一些不透明图层做裁剪、把被完全遮挡的图层剔除。所以你在dumpsys SurfaceFlinger里看到的图层数，和最终 HWC 实际处理的图层数可能不一样。排查时要以 HWC 那一侧的输入为准，而不是应用提交了多少个 Surface。

提示：图层数超限导致的退化，典型特征是"图层一多就退化，图层少就正常"。如果你发现某个页面固定在某些操作后开始掉帧，先数一数那一刻的图层数量。

2.2 格式、缩放与旋转的硬约束

HWC 对图层格式有要求。它通常支持 RGBA8888、RGBX8888 这类常见格式，但对一些特殊格式（比如某些 YUV 格式、带 alpha 的特殊排布）支持有限。视频播放场景里，如果解码输出的格式 HWC 不认，就会退化成 GPU 合成，这也是为什么有些视频播放器一播放就功耗飙升。

缩放和旋转也是重灾区。很多 HWC 硬件对缩放比例有范围限制，比如只支持 1/4 到 4 倍之间的缩放，超出范围就拒绝。旋转同理，硬件可能只支持 0/90/180/270 这几种正交旋转，任意角度旋转就得 GPU 来。所以一个带任意角度旋转动画的 View，在动画过程中很容易触发退化。

2.3 遮挡关系与混合模式

HWC 处理图层叠加时，对遮挡和混合有要求。如果上层图层是半透明的，HWC 需要做 alpha blending，大部分硬件支持，但如果混合模式比较特殊（比如某些 blend mode、颜色矩阵变换），硬件可能不支持。另外，如果图层之间有复杂的遮挡关系，硬件叠加的判定也会变复杂，某些实现会选择直接退回 GPU 求稳。

2.4 安全图层与受保护内容

涉及 DRM 保护内容的图层（比如某些流媒体视频），通常要求走 secure overlay 通道。如果 secure 通道被占用或者配置不对，这类图层也可能退化。这一块和具体平台强相关，排查时需要看厂商的 HWC 日志。

把上面这些约束整理成一张表，排查时对照着看会快很多：

这张表不是让你背，而是给你一个"退化归因"的检查清单。实际排查中，大部分退化都能归到其中一两类。

3. 退化是怎么被观测到的：从 dumpsys 到 systrace 的完整链路

光知道原理不够，得能看见退化。这一节讲怎么把退化"抓现行"，包括命令、日志字段和判断方法。这部分是实操重点，建议边看边在设备上敲。

3.1 dumpsys SurfaceFlinger 里的关键信息

最常用的入口是dumpsys SurfaceFlinger。这个命令输出很长，重点看合成相关的部分。较新版本的 Android 里，输出中会有 HWC 的合成统计，包括每个显示设备上 HWC 合成了多少图层、GPU 合成了多少图层。

adb shell dumpsys SurfaceFlinger

在输出里搜索HWC或者Composition相关的段落。你会看到类似"Display 0 HWC layers: X, Client layers: Y"这样的统计。Client layers 就是被 GPU 合成的图层数，这个数字持续大于 0，就说明存在退化。

另一个有用的命令是带--display-id参数的版本，可以只看某个显示设备：

adb shell dumpsys SurfaceFlinger --display-id

注意：不同 Android 版本和厂商定制，dumpsys 的输出格式差异很大。如果找不到 HWC 统计字段，可以试试dumpsys SurfaceFlinger --latency看帧延迟，或者直接看厂商提供的调试节点。

3.2 用 systrace/perfetto 看合成路径

dumpsys 给的是统计快照，要看时序就得用 systrace 或 perfetto。抓一段滑动操作的 trace，在 SurfaceFlinger 的 track 里找onMessageInvalidate、composite这些 slice，展开后能看到这一帧走了 HWC 还是 GPU。

具体操作：

# 用 perfetto 抓取（新版本推荐） 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 memory # 拉取到本地 adb pull /data/misc/perfetto-traces/trace.pftrace

抓到的 trace 用 Perfetto UI 打开，在 SurfaceFlinger 进程下找HWC相关的 slice。如果看到GPU composition或者Client composition的 slice 频繁出现，就定位到退化了。

3.3 一个真实的排查案例

我之前遇到过一个列表滑动掉帧的问题。现象是：静止时流畅，一滑动就掉帧，而且掉帧有规律，大概每滑几屏就卡一下。

第一步，dumpsys SurfaceFlinger看统计，发现 Client layers 在滑动时从 0 跳到 3 左右。说明滑动时确实有图层退化了。

第二步，抓 perfetto，看退化发生在哪一帧。发现退化集中在列表快速滚动、新 item 进入屏幕的那几帧。

第三步，数图层。这个列表每个 item 有背景、图片、标题、副标题、分割线，加上顶部悬浮的搜索栏、底部导航栏，一屏内图层数轻松超过 8 个。而设备的 HWC overlay 通道只有 6 个。图层数超限，就是根因。

第四步，验证。把列表 item 的多个 TextView 合并成一个自定义 View 绘制，减少图层数，退化明显减少，掉帧也缓解了。这个案例说明：图层数超限是最常见、也最容易通过 UI 结构调整解决的退化原因。

4. 退化的常见成因分类与逐项排查

上一节讲了怎么观测，这一节把成因系统化。我把退化成因分成四大类：图层数量类、格式与变换类、资源竞争类、配置与策略类。每一类给出排查方法和判断依据。

4.1 图层数量类退化

这是最普遍的一类。判断方法很简单：看退化是否和图层数量正相关。你可以做一个实验，在一个页面里逐步增加可见 View，观察 Client layers 的变化。

排查步骤：

1. 用dumpsys SurfaceFlinger记录当前页面的图层数。
2. 用 Layout Inspector 或者dumpsys activity top看 View 树，找出哪些 View 是独立图层。
3. 重点看那些"本可以合并却独立成层"的 View，比如带alpha的 View、带elevation的 View、SurfaceView、TextureView。

这里有个经验：elevation和alpha是图层杀手。一个 View 只要设置了非零 elevation 或者非 1.0 的 alpha，系统就可能给它单独开一个图层（RenderNode）。列表里如果每个 item 都有阴影，图层数会迅速膨胀。

4.2 格式与变换类退化

这类退化的特征是"特定内容才退化"。比如只有播放视频时退化，只有做旋转动画时退化。

排查方法：

• 视频场景：看解码器输出格式，对比 HWC 支持的格式列表。可以用dumpsys media.codec看解码器状态。
• 旋转场景：把旋转角度改成 90 的整数倍，看退化是否消失。如果消失，说明是任意角度旋转导致的。
• 缩放场景：把缩放比例调整到 1:1 或者常见比例，看退化是否改善。

4.3 资源竞争类退化

这类比较隐蔽。HWC 的 overlay 通道是有限资源，多个显示设备、多个 secure 通道会互相抢占。比如外接显示器时，主屏的 overlay 通道可能被分走，导致主屏退化。

还有一种情况是带宽竞争。当 GPU 和显示控制器同时抢内存带宽时，HWC 可能主动放弃一些图层，避免带宽打满导致更严重的卡顿。这类退化在低端设备上尤其常见。

4.4 配置与策略类退化

这类是"人为"造成的。比如 HWC 的某些优化开关被关掉了，或者 SurfaceFlinger 的合成策略配置不当。

常见的配置点：

• debug.sf.hwc.min.duration：控制 HWC 合成的最小间隔，配置不当会导致 HWC 被跳过。
• debug.sf.enable_hwc_vds：虚拟显示相关的 HWC 开关。
• 厂商自定义的 HWC 策略节点，通常在/sys或/proc下。

提示：改这些配置前一定要确认平台文档，乱改可能导致显示异常甚至黑屏。建议在可恢复的环境里测试。

把四类成因和排查手段整理一下：

5. 防治策略：从 UI 结构到系统配置的层层设防

知道了成因，防治就有方向了。我把防治策略按"改动成本从低到高"排序，优先做成本低、收益高的。

5.1 应用层：减少不必要的图层

这是性价比最高的一招。核心思路是：能合并的 View 就合并，能不用独立图层的就不用。

具体做法：

• 去掉不必要的elevation。阴影可以用 drawable 或者自定义绘制实现，不一定非要 elevation。
• 慎用alpha动画。如果只是淡入淡出，考虑用ViewPropertyAnimator配合硬件层，动画结束后及时清理 layer。
• 列表 item 里的多个 TextView，如果样式固定，可以合并成一个自定义 View 用 Canvas 绘制。
• 避免滥用SurfaceView和TextureView。视频播放优先用SurfaceView，它对 HWC 更友好。

我实测过一个列表页，把 item 里的 5 个 TextView 合并成 1 个自定义 View 后，图层数从 12 降到 6，退化基本消失，滑动帧率从 45 提升到 58 左右。这个收益非常可观。

5.2 系统层：合理配置 HWC 策略

系统层的调整需要 Framework 或 ROM 权限。核心是让 HWC 在关键场景优先工作。

一个常见做法是给关键场景（比如视频播放、游戏）设置 HWC 优先级，让这些场景的图层优先走硬件合成。具体实现依赖平台，通常通过 HWC 的setLayerCompositionType接口或者厂商的策略配置。

另一个做法是调整 SurfaceFlinger 的合成决策。AOSP 里 SurfaceFlinger 会根据 HWC 的getChangedCompositionTypes返回值决定哪些图层走 GPU。如果发现 HWC 过于保守，可以检查它的能力上报是否准确。

5.3 平台层：HWC 实现本身的优化

这一层是 SoC 厂商的领域，但作为系统开发者，你可以推动厂商优化。常见的优化点包括：

• 扩大 overlay 通道数（硬件限制，改不了）。
• 优化格式支持列表，增加对常见视频格式的硬件支持。
• 改进缩放和旋转的硬件支持范围。
• 优化带宽调度，减少资源竞争导致的退化。

如果你在做 ROM 定制，可以和厂商 FAE 沟通这些点，通常厂商会有对应的 patch 或配置。

5.4 一个防治效果的验证方法

改完之后怎么验证有效？我一般用这套组合：

1. 用dumpsys SurfaceFlinger对比改动前后的 Client layers 统计。
2. 用 perfetto 抓同样操作的 trace，对比 GPU composition slice 的数量。
3. 用dumpsys gfxinfo看应用的帧耗时分布。
4. 有条件的话用功耗仪测同样操作的功耗变化。

四个指标里，Client layers 和 GPU composition slice 数量是最直接的。如果这两个明显下降，说明防治生效了。

6. 几个容易踩的坑和我的实操心得

最后这部分是我踩过的坑和一些不太写在文档里的经验，分享出来希望能帮你少走弯路。

第一个坑：以为退化一定是坏事。其实不是。有些场景下 GPU 合成反而更合适，比如图层内容频繁变化、HWC 合成需要额外拷贝的情况。盲目追求"零退化"可能适得其反。判断标准应该是"这个场景下哪种合成方式总代价更低"，而不是"退化数越少越好"。

第二个坑：只看 dumpsys 不看时序。dumpsys 是快照，可能刚好抓到一个正常帧。一定要结合 perfetto 看时序，确认退化是持续的还是偶发的。偶发退化往往不是大问题，持续退化才需要处理。

第三个坑：忽略厂商定制。AOSP 的 HWC 逻辑和厂商实现可能差很远。我遇到过一个平台，它的 HWC 对某个格式的支持在文档里写了支持，实际却会退化，最后是厂商确认了实现上的 bug。所以排查时不要完全信文档，要以实测为准。

第四个坑：改配置不备份。HWC 相关配置改错了可能导致显示异常，一定要在能恢复的环境里操作，改之前记录原始值。

一个实用技巧：如果你怀疑是图层数超限，可以临时把一些 View 的visibility设为GONE，快速验证图层数对退化的影响。这个方法比改代码重新编译快得多，适合快速定位。

还有一个经验：关注系统版本差异。Android 12 之后 SurfaceFlinger 的合成逻辑有较大调整，HWC 的交互方式也变了。同一个问题在不同版本上的表现可能完全不同，排查时先确认系统版本，再对照对应版本的 AOSP 源码看合成逻辑。

关于工具，除了 dumpsys 和 perfetto，dumpsys SurfaceFlinger --latency对看帧延迟很有用，dumpsys gfxinfo对看应用侧渲染耗时很有用。这几个工具配合起来，基本能覆盖从应用到显示的整条链路。真正把 HWC 退化问题吃透，靠的不是记住某个命令，而是理解"图层从应用到显示"的完整流转过程，知道每一步可能在哪里出问题。这个过程需要反复实践，多抓几次 trace，多对比几次改动前后的数据，手感自然就来了。