做底层显示优化这几年和 HWC 硬件合成器打交道的次数比和 HR 打交道的次数还多。很多人对 Android 图形栈的印象停留在 SurfaceFlinger 接收 App 的 Buffer然后直接送显实际链路里还有一个工作量巨大的“二道贩子”——HWC。最近整理手头项目时把从 SurfaceFlinger 到显示驱动的整条合成路径重新捋了一遍踩了不少坑这里把完整流程和实操排障经验一次说清。这篇内容适合系统工程师、图形性能优化岗位也适合想知道 App 掉帧到底卡在哪一环的进阶应用开发者。1. SurfaceFlinger 的上游是谁在产生“合成任务”要讲 HWC必须先搞明白它服务的对象。很多人把 SurfaceFlinger 当成“把图层合成再显示”的唯一组件这句话对但不全对。SurfaceFlinger 确实拿了所有 App 和系统 UI 的 Layer但它不一定自己合它更像一个调度中枢决定哪些图层由自己处理、哪些交给 HWC再把任务分发下去。1.1 从 CPU 合成到 GPU 合成再到硬件合成Android 早期版本窗口合成是在 CPU 里干的每一帧把所有 Layer 的像素逐行拷贝到一个大的 FrameBuffer再通过 FB 设备送去显示。这种方式实现简单但 720p 时代就已经撑不住了CPU 要搬运的数据量动辄十几 MB再加上 DPI 越来越高纯 CPU 合成基本是灾难。后来开始用 GPU 合成也就是 OpenGL ES 把各个 Layer 当着色器里的纹理绘制到目标 buffer。GPU 比 CPU 快很多而且能处理旋转、缩放、混合这些复杂效果。但 GPU 合成有一个致命问题——功耗。每帧即使屏幕上只有一个静态图标GPU 也要把整屏缓冲重画一遍GPU 频率起来之后发热和耗电都会明显上升最典型的表现就是刷网页时手机发烫。所以 Android 引入 HWC 硬件合成器的初衷就是为了“能省则省”。HWC 是 Hardware Module 形态的 HAL 层实现直接对接 SoC 的显示控制器Display Controller或独立 Overlay 引擎。它能够把多层带有不同格式、不同位置的图层直接通过硬件 Plane 做叠加输出不需要 GPU 参与像素级搬运。1.2 HWC 到底管什么、不管什么很多新手会把 HWC 和渲染混在一起这里先划清边界。HWC 不做任何“绘制”工作它不认识 View 树不执行 shader不做 Skia/OpenGL 渲染。它只负责把已经由 App/系统进程画好的 Layer在显示输出前做最后一级合成compose与显示时序同步present。它可以管理的是图层的叠加顺序、透明度混合、裁剪、旋转、缩放、色彩空间转换部分平台支持、帧同步与 Vsync 信号、硬件 Plane 的分配与切换。它不管的是View 的 measure/layout/draw、GPU 里 draw call 的发起、上层业务逻辑这些统统与 HWC 无关。这个划分非常重要。实际排障时如果一帧画面内容本身错了比如文字模糊、颜色不对往往问题在 App 渲染或者 Buffer 传递链路如果画面撕裂、闪屏、掉帧节奏不对、低负载下硬件资源占用却很高那大概率要查 HWC 和显示驱动这一层。2. SurfaceFlinger 的合成主流程任务如何派发到 HWCSurfaceFlinger 每一帧的合成工作不是收到 buffer 就开始干的而是要等硬件 Vsync 信号。Vsync 相当于一个节拍器它告诉整个系统“这一帧的开始时间到了大家准备干活。”2.1 从 Vsync 到 BufferQueue再到 Layer 提交整个 Chain 大致是DisplayController 产生 Vsync 中断驱动上报到 SurfaceFlinger 里的 DispSync 模块SurfaceFlinger 通过 signal 唤醒正在等待的 App 绘制线程同时自己也准备合成。App 端一帧画完后通过 BufferQueue 把 Buffer 交给 SurfaceFlinger 对应的 Layer。这里有个容易忽略的点SurfaceFlinger 并不全量重画 Layer它维护了一个 dirty 状态。只有“几何属性发生变化”或“有新 buffer 入队”的 Layer 才需要处理。比如一个视图只是透明度从 0.5 改成 0.4这也算几何/状态变化Layer 要重新参与合成决策。2.2 doComposition 与 validate/present 双阶段SurfaceFlinger 的核心合成路径可以简化成这几步onMessageInvalidate - handleMessageTransaction - handleMessageInvalidate - rebuildLayerStacks - calculateWorkingSet - setUpHWComposer - hwc-validateDisplay (HWC 2.x) - 根据 validate 结果调整合成策略 - doComposition (SF 负责的部分) - hwc-presentDisplay (HWC 2.x) - postComposition这个流程里最关键的是 validate/present 的拆分。HWC 1.x 时代叫 prepare/setprepare 阶段 HWC 会检查当前图层属性是否在硬件能力范围内能支持的返回 HWC_OVERLAY不能支持的返回 HWC_GEOMETRY_CHANGED 或要求用 GPU 合成。HWC 2.x 之后改成 validate/present语义更清晰validate 只是“问一下”present 才是真正把配置下发到硬件。2.3 客户端合成与设备合成的分工逻辑SurfaceFlinger 的合成策略核心就是一句话能在 HWC 做的就不在 GPU 做。但也未必因为 HWC 硬件能力有限不是所有 Layer 都能被硬件 Plane 接收。如果当前 Layer 集合里有任意一个 Layer 的属性超出了 HWC 支持范围整个合成就会被拆开超范围的 Layer 先由 SurfaceFlinger 用 GPU 合成到一个中间 buffer称为 Client CompositionCU然后这个中间 buffer 连同其他走得通 HWC 的 Layer 一起交给 HWC 做最终输出Device Composition。这个过程叫混合合成 / Mixed Composition。我实际调试时dumpsys SurfaceFlinger 里最常见的三层结构就是状态栏 Layer、内容 Layer、导航栏 Layer。三四个图层且没有复杂特效时HWC 完全能独立完成所有合成GPU 负载接近于零这就是 HWC 最理想的运行状态。但一旦 App 在内容 Layer 上搞了大量半透明叠加、复杂圆角裁剪、模糊效果HWC 的 Plane 带宽和格式支持很可能就不够了SF 会强制把这块内容用 GPU 预合成一次再给 HWC 发。说白了就是能省则省省不了才自己上。3. HWC HAL 层核心版本差异、合成决策与实现骨架HWC 本身是一个 HAL 动态库不同 SoC 厂商的实现天差地别。你做 MTK 项目和做高通项目看到的内存布局、调试节点、错误日志完全不一样但上层接口是一致的。3.1 HWC API 演进从 1.x 到 2.x/3.x先看版本。Android 8.0 之前主流是 HWC 1.x接口是 prepare/setAndroid 8.0 之后 HWC 2.x 成为主流一直用到现在新平台上也出现了 HWC 3.x 形态的接口整合但底层核心概念没有变。版本核心接口关键差异HWC 1.xprepare / setprepare 阶段一次性返回所有 Layer 的合成类型HWC 2.xvalidate / presentvalidate 支持增量更新减少预算开销HWC 3.x接口整合支持更多属性往现代 DRM/KMS 抽象方向收敛HWC 2.x 的对象模型也比较规整设备层面有一个 hwc2_device显示层面有 Display显示内容里有 Layer。所有操作都通过 GetFunction 拿到函数指针调用类似一种轻量级接口分发。常见的关键 Descriptor 有HWC2_FUNCTION_VALIDATE_DISPLAY HWC2_FUNCTION_PRESENT_DISPLAY HWC2_FUNCTION_CREATE_LAYER HWC2_FUNCTION_SET_LAYER_BUFFER HWC2_FUNCTION_SET_LAYER_SOURCE_CROP HWC2_FUNCTION_SET_LAYER_DISPLAY_FRAME HWC2_FUNCTION_SET_LAYER_BLEND_MODE HWC2_FUNCTION_SET_LAYER_Z_ORDER每个 Layer 在 HWC 里最终被映射成硬件 Plane 上的一个窗口配置项包括源裁剪区域、目标显示区域、混合模式、Z 序、透明度、旋转方式等。3.2 合成决策HWC 为什么拒绝某些 LayerHWC 的合成决策不是纯软件规则它受硬件限制的约束非常明显。不同 SoC 显示控制器的 Overlay Plane 数量是有限的比如常见的 3 到 5 个。如果你有 6 个普通 Layer必然有 Layer 无法直接分配到 Plane有硬件 Plane 却因为缓冲区格式不支持比如某个 YUV 格式没有对应的 scaling 能力也会拒绝。实际项目里我遇到最多的拒绝原因是这几个硬件 Plane 不够Layer 数量超过 Overlay 通道上限。这种通常会让最复杂的 App 内容层走 GPU 预合成。缓冲格式不支持比如某些 SurfaceView 视频层用了 HDR 10bit老平台的 Plane 不支持只能交给 GPU 做 tone-mapping 合成。旋转角度支持不完整比如 90° 旋转硬件支持但 180° 或者带镜像翻转的组合不支持。混合模式限制彩色字体、硬件 cursor 这类特殊 buffer 有时也走不通。带宽预算不足HWC 基于当前分辨率、刷新率、层数量估算 pixel throughput如果超过预算它宁可把部分图层推回 GPU也不会硬着头皮上否则显示控制器会丢数据。HWC 2.x 里 validate 阶段会返回changedTypesSurfaceFlinger 根据这个变化判断哪些 Layer 需要从 DEVICE 合成改成 CLIENT 合成然后重新走一遍合成策略直到 HWC 接受所有当前策略为止。3.3 一个 HWC 实现的典型骨架厂商 HWC 实现内部通常有一棵合成决策树。以集成 DRM/KMS 能力的平台为例它的实现大体上是这样class VirtualDisplay : public hwc2_display { public: int32_t validate(uint32_t* outNumTypes, uint32_t* outNumRequests) override { // 1. 遍历所有 Layer检查硬件 Plane 是否匹配 // 2. 如果 Plane 不支持则把该 Layer 标记为 CLIENT // 3. 返回 changedTypes 给 SurfaceFlinger } int32_t present(int32_t* outRetireFence) override { // 1. 把所有 Layer 的 buffer 和属性映射到 DRM framebuffer // 2. 通过 atomic commit 下发到内核 // 3. 拿到 retire fence 返回 } };真正动手写过 HWC 的人都知道最磨人的不是接口实现而是“硬件能力声明”。很多显示控制器的文档非常简略你以为某个格式可以缩放驱动加载后才发现 plane 不支持最后只能靠 validate 阶段反复试错。所以厂商实现里一定有一堆 workaround专门针对特定 SoC 或特定分辨率场景做限制。4. 显示驱动层的衔接fence、vsync 与页翻转HWC HAL 之下就是内核驱动层。现代 SoC 上大多数平台已经把 HWC 的数据通道统一到 DRM/KMS 框架上HWC 扮演 userspace 配置者内核驱动负责实际的显示时序和像素输出。4.1 fence 机制合成任务的“信号灯”整个合成链路里fence 是最容易踩坑、也最值得理解的概念。fence 本质上是一个基于内核 sync_file 的同步原语可以理解成一个带文件描述符的事件信号。HWC 发给驱动一个 buffer驱动还没扫描到这一帧此时 user space 不能把这个 buffer 释放给生产者复用否则画面就会撕裂甚至内容错乱。常见的三种 fence 分别是 acquire fence、release fence、present(retire) fence。acquire fence 表示生产者写入完成合成端可以安全读取release fence 表示合成端已经读完了BufferQueue 可以回收复用present fence 表示画面已经真正出现在屏幕上主要用于统计实际帧率和 jank。排查 fence 问题时我一般这样操作adb shell cat /sys/kernel/debug/sync 2/dev/null adb shell cat /sys/kernel/debug/dri/0/state 2/dev/null这些节点通常需要 root而且不是所有平台都开。如果没有 debugfs 权限只能回上层看dumpsys SurfaceFlinger里每个 Layer 的 acquire/release fence 状态如果发现 fence 长时间没有 signal基本可以断定驱动或者 HWC 的等待逻辑出了问题。4.2 Vsync 与 VBlank节拍器的来源Vsync 信号从哪来最底层来自显示控制器在行扫描开始前的一小段空档也就是 VBlank 区域。内核驱动把 VBlank 中断上报给用户态SurfaceFlinger 再基于这些硬件中断校准自己的节拍。这里要区分三个概念屏幕刷新率是面板物理帧率比如 60Hz 即每 16.6ms 完成一帧完整扫描系统 Vsync 是 SurfaceFlinger 分发给应用和合成的同步信号真正的帧率是系统在一秒内完成合成并送给屏幕的帧数。VBlank 不产生不代表你有 60fps掉帧通常就发生在 VBlank 的节拍里有一拍没接上。调试刷新率相关的抖动建议先看这两个输出adb shell dumpsys SurfaceFlinger | grep -A 5 Refresh Rate adb shell dumpsys SurfaceFlinger | grep -i vsync如果发现 Vsync 周期忽长忽短优先怀疑是 CPU 调度延迟、中断被关闭、或者 panel 自刷新PSR切换时机不对这些都在显示驱动层。4.3 页翻转与 DRM Atomic Commit现代显示控制器天生是“双缓冲”或“多缓冲”工作的。一帧正在扫描输出时HWC 必须把下一帧配置到另一个 buffer 或 Plane 区域等下一个 VBlank 再把控制权切过去这就是页翻转page flip。DRM/KMS 里这套逻辑被抽象成 Plane/CRTC/Encoder/Connector 四件套Plane 对应一个可合成的图像层HWC 的每个 Layer 最终映射到一个 Plane。CRTC 是显示控制器核心负责时序生成和扫描输出。Encoder/Connector 负责把信号转成 HDMI/DSI/DP 等物理输出。HWC 要做的事情就是在一个 atomic commit 时把所有 Plane 的 buffer、crop、position、z-order、blend 一起提交给内核内核校验通过后在下一个 VBlank 原子切换。整个过程不允许出现中间态否则就会撕裂。5. 实战排查从 dumpsys 到 trace 的完整排障姿势理论再多最后还是要落地到排障。我在项目里最常用的就是三件套dumpsys 快照、atrace/systrace、以及内核和 HAL 层的日志节点。5.1 第一招读 dumpsys SurfaceFlinger很多时候拿到一台设备什么都不清楚第一件事就是抓快照。adb shell dumpsys SurfaceFlinger重点看这几个段落DeviceComposition 状态 Display 0: 显示状态、Vsync偏移、功率模式 CompositionDisplayId、帧计数器 每个 Layer 的关键片段类似 layerId123 Layer Name ... compositionTypeDEVICE # 表示 HWC 直接合成 compositionTypeCLIENT # 表示 SF 用 GPU 预合成看到 CLIENT 比例很高说明 HWC 没怎么干活多半是图层属性太复杂或者 Plane 资源不够。看到 DEVICE 比例高但帧率依然低那问题更可能在 HWC 到驱动的链路上比如页翻转太慢、fence 等待过长。5.2 第二招抓一次完整的显示链路 tracesystrace 虽然名字旧但通过 Perfetto 打开 trace 依然是最直观的。抓取命令adb shell atrace --async_start -t 10 sf hwc gfx view bionic adb shell atrace --async_stop -z -o /data/local/tmp/trace.dat adb pull /data/local/tmp/trace.dat打开 trace 后重点看 SurfaceFlinger 的doComposition、HWC 的validateDisplay、presentDisplay这三个 slice 的时长。正常情况下60Hz 屏幕每帧留给合成的预算大约 16.6ms其中 HWC validate 应该在 0.2ms 以内present 也应在 1ms 上下。如果 present 动不动超过 5ms驱动层页翻转必然有问题。还有一个小技巧在开发者选项里打开“停用 HW 叠加层”会强制所有 Layer 走 GPU 合成。如果开启后问题消失那基本上坐实了 HWC 硬件路径有问题如果开启后更卡说明 HWC 本身工作良好问题出在 SF 上层或 App 的渲染逻辑。5.3 实战案例App 滑动时周期性掉帧之前遇到一个现象某个 App 滑动列表时帧率固定在 45fps 左右怎么优化布局都没用。从 dumpsys 看到每个 Layer 都是 DEVICE 合成非常干净说明 HWC 没有拒绝GPU 也几乎没活干。但 trace 里发现 HWC 的 presentDisplay slice 每三帧就出现一次 3ms 左右的尖峰而且和 CPU 调频相关。最后定位到显示驱动里某个 DMA 通道的带宽仲裁策略当 CPU 在特定频率区间时该通道被其他外设抢占导致页翻转的 retire fence 延迟。这种问题你用常规的“减少合成层”“优化布局”完全摸不到必须把注意力放到 HWC 到驱动这条底线上。6. 常见问题速查表与排查方向实际项目中反复遇到的 HWC 相关问题我整理成了一张速查表。遇到问题先对表查一遍比自己翻代码快得多。症状可能原因排查方向全屏闪烁/花屏HWC 页翻转时序不对fence 等待出错查 dmesg 中 display controller 错误抓 trace 看 presentFence 是否超时低负载掉帧HWC 拒绝部分 Layer走了 GPU 合成dumpsys SF 看 compositionType检查 Layer 属性是否超范围视频播放花屏视频 Layer 使用的 YUV 格式超出 Plane 支持范围查看视频格式HWC 日志中找 plane 不支持输出强制让视频层走 GPU 合成对比屏幕休眠后无法唤醒Panel/Display 驱动 resume 失败或 HWC 状态错乱查内核 log检查 HWC 的 onDisplayDisconnect 处理是否有空指针变色/偏白Blend mode 或色彩空间配置错误检查 Layer 的 blendMode关掉 HDR 模式对比多屏扩展显示异常Vsync 不同步副屏和主屏掉帧不一致查看每个 Display 的 present fence确认所有 CRTC 的 VBlank 中断正常长时间运行后越来越卡Plane 资源泄漏或 HWC 线程被优先级翻转dumpsys meminfo 看 HWC 进程内存检查线程优先级和 lock 持有时间另外还有几个经验值可以分享。HWC 合成决策里每多一层透明混合bus 带宽消耗不是线性的而是近似于像素数乘 alpha 层数的叠加。所以我在做性能评估时第一眼看的永远是屏幕上同时叠加的半透明 Layer 总数而不是屏幕分辨率。这个数值直接决定了 HWC 负担和 GPU 被拉进来的概率。个人体会是排查 HWC 问题最忌一开始就盯代码。先把整条链路的日志和 trace 抓全从 dumpsys 看策略结果从 trace 看耗时分布从 dmesg 看驱动异常再回到 HWC 源码里找对应分支这样定位问题的效率最高。很多时候你以为的 HWC 计算瓶颈最后只是驱动里一个不太显眼的 I/O 调度策略问题。
做底层显示优化这几年和 HWC 硬件合成器打交道的次数比和 HR 打交道的次数还多。很多人对 Android 图形栈的印象停留在 SurfaceFlinger 接收 App 的 Buffer然后直接送显实际链路里还有一个工作量巨大的“二道贩子”——HWC。最近整理手头项目时把从 SurfaceFlinger 到显示驱动的整条合成路径重新捋了一遍踩了不少坑这里把完整流程和实操排障经验一次说清。这篇内容适合系统工程师、图形性能优化岗位也适合想知道 App 掉帧到底卡在哪一环的进阶应用开发者。1. SurfaceFlinger 的上游是谁在产生“合成任务”要讲 HWC必须先搞明白它服务的对象。很多人把 SurfaceFlinger 当成“把图层合成再显示”的唯一组件这句话对但不全对。SurfaceFlinger 确实拿了所有 App 和系统 UI 的 Layer但它不一定自己合它更像一个调度中枢决定哪些图层由自己处理、哪些交给 HWC再把任务分发下去。1.1 从 CPU 合成到 GPU 合成再到硬件合成Android 早期版本窗口合成是在 CPU 里干的每一帧把所有 Layer 的像素逐行拷贝到一个大的 FrameBuffer再通过 FB 设备送去显示。这种方式实现简单但 720p 时代就已经撑不住了CPU 要搬运的数据量动辄十几 MB再加上 DPI 越来越高纯 CPU 合成基本是灾难。后来开始用 GPU 合成也就是 OpenGL ES 把各个 Layer 当着色器里的纹理绘制到目标 buffer。GPU 比 CPU 快很多而且能处理旋转、缩放、混合这些复杂效果。但 GPU 合成有一个致命问题——功耗。每帧即使屏幕上只有一个静态图标GPU 也要把整屏缓冲重画一遍GPU 频率起来之后发热和耗电都会明显上升最典型的表现就是刷网页时手机发烫。所以 Android 引入 HWC 硬件合成器的初衷就是为了“能省则省”。HWC 是 Hardware Module 形态的 HAL 层实现直接对接 SoC 的显示控制器Display Controller或独立 Overlay 引擎。它能够把多层带有不同格式、不同位置的图层直接通过硬件 Plane 做叠加输出不需要 GPU 参与像素级搬运。1.2 HWC 到底管什么、不管什么很多新手会把 HWC 和渲染混在一起这里先划清边界。HWC 不做任何“绘制”工作它不认识 View 树不执行 shader不做 Skia/OpenGL 渲染。它只负责把已经由 App/系统进程画好的 Layer在显示输出前做最后一级合成compose与显示时序同步present。它可以管理的是图层的叠加顺序、透明度混合、裁剪、旋转、缩放、色彩空间转换部分平台支持、帧同步与 Vsync 信号、硬件 Plane 的分配与切换。它不管的是View 的 measure/layout/draw、GPU 里 draw call 的发起、上层业务逻辑这些统统与 HWC 无关。这个划分非常重要。实际排障时如果一帧画面内容本身错了比如文字模糊、颜色不对往往问题在 App 渲染或者 Buffer 传递链路如果画面撕裂、闪屏、掉帧节奏不对、低负载下硬件资源占用却很高那大概率要查 HWC 和显示驱动这一层。2. SurfaceFlinger 的合成主流程任务如何派发到 HWCSurfaceFlinger 每一帧的合成工作不是收到 buffer 就开始干的而是要等硬件 Vsync 信号。Vsync 相当于一个节拍器它告诉整个系统“这一帧的开始时间到了大家准备干活。”2.1 从 Vsync 到 BufferQueue再到 Layer 提交整个 Chain 大致是DisplayController 产生 Vsync 中断驱动上报到 SurfaceFlinger 里的 DispSync 模块SurfaceFlinger 通过 signal 唤醒正在等待的 App 绘制线程同时自己也准备合成。App 端一帧画完后通过 BufferQueue 把 Buffer 交给 SurfaceFlinger 对应的 Layer。这里有个容易忽略的点SurfaceFlinger 并不全量重画 Layer它维护了一个 dirty 状态。只有“几何属性发生变化”或“有新 buffer 入队”的 Layer 才需要处理。比如一个视图只是透明度从 0.5 改成 0.4这也算几何/状态变化Layer 要重新参与合成决策。2.2 doComposition 与 validate/present 双阶段SurfaceFlinger 的核心合成路径可以简化成这几步onMessageInvalidate - handleMessageTransaction - handleMessageInvalidate - rebuildLayerStacks - calculateWorkingSet - setUpHWComposer - hwc-validateDisplay (HWC 2.x) - 根据 validate 结果调整合成策略 - doComposition (SF 负责的部分) - hwc-presentDisplay (HWC 2.x) - postComposition这个流程里最关键的是 validate/present 的拆分。HWC 1.x 时代叫 prepare/setprepare 阶段 HWC 会检查当前图层属性是否在硬件能力范围内能支持的返回 HWC_OVERLAY不能支持的返回 HWC_GEOMETRY_CHANGED 或要求用 GPU 合成。HWC 2.x 之后改成 validate/present语义更清晰validate 只是“问一下”present 才是真正把配置下发到硬件。2.3 客户端合成与设备合成的分工逻辑SurfaceFlinger 的合成策略核心就是一句话能在 HWC 做的就不在 GPU 做。但也未必因为 HWC 硬件能力有限不是所有 Layer 都能被硬件 Plane 接收。如果当前 Layer 集合里有任意一个 Layer 的属性超出了 HWC 支持范围整个合成就会被拆开超范围的 Layer 先由 SurfaceFlinger 用 GPU 合成到一个中间 buffer称为 Client CompositionCU然后这个中间 buffer 连同其他走得通 HWC 的 Layer 一起交给 HWC 做最终输出Device Composition。这个过程叫混合合成 / Mixed Composition。我实际调试时dumpsys SurfaceFlinger 里最常见的三层结构就是状态栏 Layer、内容 Layer、导航栏 Layer。三四个图层且没有复杂特效时HWC 完全能独立完成所有合成GPU 负载接近于零这就是 HWC 最理想的运行状态。但一旦 App 在内容 Layer 上搞了大量半透明叠加、复杂圆角裁剪、模糊效果HWC 的 Plane 带宽和格式支持很可能就不够了SF 会强制把这块内容用 GPU 预合成一次再给 HWC 发。说白了就是能省则省省不了才自己上。3. HWC HAL 层核心版本差异、合成决策与实现骨架HWC 本身是一个 HAL 动态库不同 SoC 厂商的实现天差地别。你做 MTK 项目和做高通项目看到的内存布局、调试节点、错误日志完全不一样但上层接口是一致的。3.1 HWC API 演进从 1.x 到 2.x/3.x先看版本。Android 8.0 之前主流是 HWC 1.x接口是 prepare/setAndroid 8.0 之后 HWC 2.x 成为主流一直用到现在新平台上也出现了 HWC 3.x 形态的接口整合但底层核心概念没有变。版本核心接口关键差异HWC 1.xprepare / setprepare 阶段一次性返回所有 Layer 的合成类型HWC 2.xvalidate / presentvalidate 支持增量更新减少预算开销HWC 3.x接口整合支持更多属性往现代 DRM/KMS 抽象方向收敛HWC 2.x 的对象模型也比较规整设备层面有一个 hwc2_device显示层面有 Display显示内容里有 Layer。所有操作都通过 GetFunction 拿到函数指针调用类似一种轻量级接口分发。常见的关键 Descriptor 有HWC2_FUNCTION_VALIDATE_DISPLAY HWC2_FUNCTION_PRESENT_DISPLAY HWC2_FUNCTION_CREATE_LAYER HWC2_FUNCTION_SET_LAYER_BUFFER HWC2_FUNCTION_SET_LAYER_SOURCE_CROP HWC2_FUNCTION_SET_LAYER_DISPLAY_FRAME HWC2_FUNCTION_SET_LAYER_BLEND_MODE HWC2_FUNCTION_SET_LAYER_Z_ORDER每个 Layer 在 HWC 里最终被映射成硬件 Plane 上的一个窗口配置项包括源裁剪区域、目标显示区域、混合模式、Z 序、透明度、旋转方式等。3.2 合成决策HWC 为什么拒绝某些 LayerHWC 的合成决策不是纯软件规则它受硬件限制的约束非常明显。不同 SoC 显示控制器的 Overlay Plane 数量是有限的比如常见的 3 到 5 个。如果你有 6 个普通 Layer必然有 Layer 无法直接分配到 Plane有硬件 Plane 却因为缓冲区格式不支持比如某个 YUV 格式没有对应的 scaling 能力也会拒绝。实际项目里我遇到最多的拒绝原因是这几个硬件 Plane 不够Layer 数量超过 Overlay 通道上限。这种通常会让最复杂的 App 内容层走 GPU 预合成。缓冲格式不支持比如某些 SurfaceView 视频层用了 HDR 10bit老平台的 Plane 不支持只能交给 GPU 做 tone-mapping 合成。旋转角度支持不完整比如 90° 旋转硬件支持但 180° 或者带镜像翻转的组合不支持。混合模式限制彩色字体、硬件 cursor 这类特殊 buffer 有时也走不通。带宽预算不足HWC 基于当前分辨率、刷新率、层数量估算 pixel throughput如果超过预算它宁可把部分图层推回 GPU也不会硬着头皮上否则显示控制器会丢数据。HWC 2.x 里 validate 阶段会返回changedTypesSurfaceFlinger 根据这个变化判断哪些 Layer 需要从 DEVICE 合成改成 CLIENT 合成然后重新走一遍合成策略直到 HWC 接受所有当前策略为止。3.3 一个 HWC 实现的典型骨架厂商 HWC 实现内部通常有一棵合成决策树。以集成 DRM/KMS 能力的平台为例它的实现大体上是这样class VirtualDisplay : public hwc2_display { public: int32_t validate(uint32_t* outNumTypes, uint32_t* outNumRequests) override { // 1. 遍历所有 Layer检查硬件 Plane 是否匹配 // 2. 如果 Plane 不支持则把该 Layer 标记为 CLIENT // 3. 返回 changedTypes 给 SurfaceFlinger } int32_t present(int32_t* outRetireFence) override { // 1. 把所有 Layer 的 buffer 和属性映射到 DRM framebuffer // 2. 通过 atomic commit 下发到内核 // 3. 拿到 retire fence 返回 } };真正动手写过 HWC 的人都知道最磨人的不是接口实现而是“硬件能力声明”。很多显示控制器的文档非常简略你以为某个格式可以缩放驱动加载后才发现 plane 不支持最后只能靠 validate 阶段反复试错。所以厂商实现里一定有一堆 workaround专门针对特定 SoC 或特定分辨率场景做限制。4. 显示驱动层的衔接fence、vsync 与页翻转HWC HAL 之下就是内核驱动层。现代 SoC 上大多数平台已经把 HWC 的数据通道统一到 DRM/KMS 框架上HWC 扮演 userspace 配置者内核驱动负责实际的显示时序和像素输出。4.1 fence 机制合成任务的“信号灯”整个合成链路里fence 是最容易踩坑、也最值得理解的概念。fence 本质上是一个基于内核 sync_file 的同步原语可以理解成一个带文件描述符的事件信号。HWC 发给驱动一个 buffer驱动还没扫描到这一帧此时 user space 不能把这个 buffer 释放给生产者复用否则画面就会撕裂甚至内容错乱。常见的三种 fence 分别是 acquire fence、release fence、present(retire) fence。acquire fence 表示生产者写入完成合成端可以安全读取release fence 表示合成端已经读完了BufferQueue 可以回收复用present fence 表示画面已经真正出现在屏幕上主要用于统计实际帧率和 jank。排查 fence 问题时我一般这样操作adb shell cat /sys/kernel/debug/sync 2/dev/null adb shell cat /sys/kernel/debug/dri/0/state 2/dev/null这些节点通常需要 root而且不是所有平台都开。如果没有 debugfs 权限只能回上层看dumpsys SurfaceFlinger里每个 Layer 的 acquire/release fence 状态如果发现 fence 长时间没有 signal基本可以断定驱动或者 HWC 的等待逻辑出了问题。4.2 Vsync 与 VBlank节拍器的来源Vsync 信号从哪来最底层来自显示控制器在行扫描开始前的一小段空档也就是 VBlank 区域。内核驱动把 VBlank 中断上报给用户态SurfaceFlinger 再基于这些硬件中断校准自己的节拍。这里要区分三个概念屏幕刷新率是面板物理帧率比如 60Hz 即每 16.6ms 完成一帧完整扫描系统 Vsync 是 SurfaceFlinger 分发给应用和合成的同步信号真正的帧率是系统在一秒内完成合成并送给屏幕的帧数。VBlank 不产生不代表你有 60fps掉帧通常就发生在 VBlank 的节拍里有一拍没接上。调试刷新率相关的抖动建议先看这两个输出adb shell dumpsys SurfaceFlinger | grep -A 5 Refresh Rate adb shell dumpsys SurfaceFlinger | grep -i vsync如果发现 Vsync 周期忽长忽短优先怀疑是 CPU 调度延迟、中断被关闭、或者 panel 自刷新PSR切换时机不对这些都在显示驱动层。4.3 页翻转与 DRM Atomic Commit现代显示控制器天生是“双缓冲”或“多缓冲”工作的。一帧正在扫描输出时HWC 必须把下一帧配置到另一个 buffer 或 Plane 区域等下一个 VBlank 再把控制权切过去这就是页翻转page flip。DRM/KMS 里这套逻辑被抽象成 Plane/CRTC/Encoder/Connector 四件套Plane 对应一个可合成的图像层HWC 的每个 Layer 最终映射到一个 Plane。CRTC 是显示控制器核心负责时序生成和扫描输出。Encoder/Connector 负责把信号转成 HDMI/DSI/DP 等物理输出。HWC 要做的事情就是在一个 atomic commit 时把所有 Plane 的 buffer、crop、position、z-order、blend 一起提交给内核内核校验通过后在下一个 VBlank 原子切换。整个过程不允许出现中间态否则就会撕裂。5. 实战排查从 dumpsys 到 trace 的完整排障姿势理论再多最后还是要落地到排障。我在项目里最常用的就是三件套dumpsys 快照、atrace/systrace、以及内核和 HAL 层的日志节点。5.1 第一招读 dumpsys SurfaceFlinger很多时候拿到一台设备什么都不清楚第一件事就是抓快照。adb shell dumpsys SurfaceFlinger重点看这几个段落DeviceComposition 状态 Display 0: 显示状态、Vsync偏移、功率模式 CompositionDisplayId、帧计数器 每个 Layer 的关键片段类似 layerId123 Layer Name ... compositionTypeDEVICE # 表示 HWC 直接合成 compositionTypeCLIENT # 表示 SF 用 GPU 预合成看到 CLIENT 比例很高说明 HWC 没怎么干活多半是图层属性太复杂或者 Plane 资源不够。看到 DEVICE 比例高但帧率依然低那问题更可能在 HWC 到驱动的链路上比如页翻转太慢、fence 等待过长。5.2 第二招抓一次完整的显示链路 tracesystrace 虽然名字旧但通过 Perfetto 打开 trace 依然是最直观的。抓取命令adb shell atrace --async_start -t 10 sf hwc gfx view bionic adb shell atrace --async_stop -z -o /data/local/tmp/trace.dat adb pull /data/local/tmp/trace.dat打开 trace 后重点看 SurfaceFlinger 的doComposition、HWC 的validateDisplay、presentDisplay这三个 slice 的时长。正常情况下60Hz 屏幕每帧留给合成的预算大约 16.6ms其中 HWC validate 应该在 0.2ms 以内present 也应在 1ms 上下。如果 present 动不动超过 5ms驱动层页翻转必然有问题。还有一个小技巧在开发者选项里打开“停用 HW 叠加层”会强制所有 Layer 走 GPU 合成。如果开启后问题消失那基本上坐实了 HWC 硬件路径有问题如果开启后更卡说明 HWC 本身工作良好问题出在 SF 上层或 App 的渲染逻辑。5.3 实战案例App 滑动时周期性掉帧之前遇到一个现象某个 App 滑动列表时帧率固定在 45fps 左右怎么优化布局都没用。从 dumpsys 看到每个 Layer 都是 DEVICE 合成非常干净说明 HWC 没有拒绝GPU 也几乎没活干。但 trace 里发现 HWC 的 presentDisplay slice 每三帧就出现一次 3ms 左右的尖峰而且和 CPU 调频相关。最后定位到显示驱动里某个 DMA 通道的带宽仲裁策略当 CPU 在特定频率区间时该通道被其他外设抢占导致页翻转的 retire fence 延迟。这种问题你用常规的“减少合成层”“优化布局”完全摸不到必须把注意力放到 HWC 到驱动这条底线上。6. 常见问题速查表与排查方向实际项目中反复遇到的 HWC 相关问题我整理成了一张速查表。遇到问题先对表查一遍比自己翻代码快得多。症状可能原因排查方向全屏闪烁/花屏HWC 页翻转时序不对fence 等待出错查 dmesg 中 display controller 错误抓 trace 看 presentFence 是否超时低负载掉帧HWC 拒绝部分 Layer走了 GPU 合成dumpsys SF 看 compositionType检查 Layer 属性是否超范围视频播放花屏视频 Layer 使用的 YUV 格式超出 Plane 支持范围查看视频格式HWC 日志中找 plane 不支持输出强制让视频层走 GPU 合成对比屏幕休眠后无法唤醒Panel/Display 驱动 resume 失败或 HWC 状态错乱查内核 log检查 HWC 的 onDisplayDisconnect 处理是否有空指针变色/偏白Blend mode 或色彩空间配置错误检查 Layer 的 blendMode关掉 HDR 模式对比多屏扩展显示异常Vsync 不同步副屏和主屏掉帧不一致查看每个 Display 的 present fence确认所有 CRTC 的 VBlank 中断正常长时间运行后越来越卡Plane 资源泄漏或 HWC 线程被优先级翻转dumpsys meminfo 看 HWC 进程内存检查线程优先级和 lock 持有时间另外还有几个经验值可以分享。HWC 合成决策里每多一层透明混合bus 带宽消耗不是线性的而是近似于像素数乘 alpha 层数的叠加。所以我在做性能评估时第一眼看的永远是屏幕上同时叠加的半透明 Layer 总数而不是屏幕分辨率。这个数值直接决定了 HWC 负担和 GPU 被拉进来的概率。个人体会是排查 HWC 问题最忌一开始就盯代码。先把整条链路的日志和 trace 抓全从 dumpsys 看策略结果从 trace 看耗时分布从 dmesg 看驱动异常再回到 HWC 源码里找对应分支这样定位问题的效率最高。很多时候你以为的 HWC 计算瓶颈最后只是驱动里一个不太显眼的 I/O 调度策略问题。
