Android View 绘制与布局：从应用到屏幕的渲染管线

本文目标：打破“只背 View 三部曲”的局限，用一条完整的渲染管线把「应用层代码」到「屏幕显示」的整个链路串联起来。不仅知其然（流程是什么），更知其所以然（为什么要这么设计）。

阅读建议：

• 想快速建立整体认知 👉 读 一、核心结论
• 想了解一帧画面的诞生全貌 👉 读 二、渲染管线与 VSYNC 机制
• 想深入理解 View 三大核心步骤与底层数据结构 👉 读 三、主线程遍历详解（measure / layout / draw）
• 遇到卡顿、拿不到宽高、自定义 View 等问题 👉 读 四、常见场景与排障指南

一、核心结论

不要把「只有 View 三步」当成渲染的全部；这三步仅仅是应用侧准备数据的过程，真正的上屏必须经过合成与显示链路。现代 Android 渲染的宏观分工如下：

• 主线程（UI 线程）：负责遍历视图树（measure / layout），并把绘制操作录制成图纸（draw 指令），不直接操作像素。
• 渲染线程（RenderThread）与 GPU：接手主线程录制好的图纸，利用 GPU 真正把指令变成像素（栅格化）。
• 系统合成守护进程（SurfaceFlinger）：负责把各个 App 和系统 UI（状态栏、导航栏）的图层合成在一起，最终送到屏幕。

二、渲染管线与 VSYNC 机制

屏幕是一行行刷新的，如果代码随时随地去修改像素，极易出现画面撕裂。为此，Android 设计了基于 VSYNC（垂直同步信号） 的节奏控制流水线。

1. 一帧画面的 5 个阶段全貌

sequenceDiagram
    participant Disp as 物理屏幕 & VSYNC
    participant Choreo as 框架层 (Choreographer)
    participant Main as 应用主线程 (UI 线程)
    participant RT as 渲染线程 (RenderThread)
    participant SF as 系统合成进程 (SurfaceFlinger)

    Disp->>Choreo: 1. 发出 VSYNC 节拍 (如每 16.6ms)
    Choreo->>Main: 2. 触发回调，唤醒主线程
    Note over Main: 3. 遍历视图树<br/>(measure -> layout -> draw)
    Main->>RT: 4. 同步绘制指令 (DisplayList)
    Note over RT: 5. GPU 栅格化，生成像素缓冲
    RT->>SF: 6. 跨进程提交缓冲
    Note over SF: 7. 多窗口/图层合成
    SF->>Disp: 8. 送显上屏 (等待下一次 VSYNC)

1. 节拍器（VSYNC）：屏幕按固定频率发出的“滴答”声，统一渲染节奏。
2. 传达室与发令枪（Choreographer）：应用调用 invalidate() 时，是向它“注册”一个任务，等待下一个 VSYNC 发令枪响，才唤醒主线程干活。
3. 主线程遍历（View 三部曲）：主线程确认视图大小（measure）、位置（layout），并录制绘制指令（draw）。
4. 独立包工头（RenderThread + GPU）：主线程录制完图纸后立刻交接给它。它负责真正的“上色”（栅格化），让主线程能解放出来去响应触摸事件。
5. 幕后大 Boss（SurfaceFlinger）：Android 专属的独立系统守护进程。负责把手机所有图层跨进程汇总上屏。

2. 底层设计的演进与解惑

• 疑问一：为什么不在 VSYNC 到来“之前”一有空就提前画好？ 为了保证画面“绝对新鲜”并将零散的更新“打包”。等到 VSYNC 到来的一瞬间才去采集触摸位置和动画时间，画出来的才最贴合用户的当下操作，极大降低了输入延迟。同时避免 16.6ms 内多次无用的重复重绘。

• 疑问二：如果超时了，错过了下一次 VSYNC 怎么办？ 如果主线程计算太耗时超过了 16.6ms，屏幕只能被迫继续显示上一帧的旧画面。用户的直观感受就是“卡了一下”，这就是掉帧（Jank）。

• 疑问三：平时开发怎么对 RenderThread 毫无感知？ 因为底层默默代工了。你照常写 onDraw()，框架把 Canvas 操作转为 DisplayList 指令交给它。正因如此，基于 RenderNode 的属性动画（如 TranslationX）即使主线程卡住也能流畅运行。

三、主线程遍历详解（measure / layout / draw）

当主线程被 VSYNC 唤醒后，ViewRootImpl.performTraversals() 开始了对视图树的遍历。

1. 视图遍历机制与数据结构模型

从底层数据结构的角度而言，Android 视图系统本质上是一棵以 ViewRootImpl 为根节点的树。视图树的渲染过程（即 performTraversals()）严格遵循树的深度优先遍历（DFS）机制。三大核心阶段在遍历模型中的映射如下：

• 测量（Measure）阶段：采用后序遍历（Post-order Traversal） 系统在处理父容器的尺寸前，必须先递归调用所有子节点的 measure() 方法。只有当所有的叶子节点和内层节点计算并确认了自身尺寸，将结果向上传递后，父容器才能基于子节点的合计约束，最终确定自身大小。

• 布局（Layout）阶段：采用先序遍历（Pre-order Traversal） 系统在定位视图时采用自顶向下的策略。父节点确定了自身的绝对坐标后，其 onLayout() 会被触发，随后系统将可用空间作为相对坐标参照系分配给内部的各个子节点。子节点必须在父节点确立参照系后，方能获得自身的最终位置。

• 绘制（Draw）阶段：基于层叠上下文的先序遍历 在硬件加速模型下，绘制指令（DisplayList）的录制自顶向下进行。系统会优先处理当前节点的背景绘制，随后通过 dispatchDraw() 触发其包含的所有子节点进行内容绘制，从而确保 UI 元素的 Z 轴遮挡关系（Z-ordering）得以正确呈现。

2. 三大阶段细节剖析

阶段一：Measure（测量）

解决“每个 View 想要多大”。父 View 会把尺寸规格打包成 MeasureSpec 向下推送到子节点。

• EXACTLY：尺寸已敲定（如 100dp 或 match_parent 且父节点有固定大小）。
• AT_MOST：不超过上限，具体多大多由子节点内容决定（通常对应 wrap_content）。
• UNSPECIFIED：上限极松，常见于 ScrollView 内部。

防坑：当父是 AT_MOST（上限）时，子若要求 match_parent，拿到的也是 AT_MOST。match_parent 在父未敲定尺寸时，语义退化为「在上限内尽量大」。

阶段二：Layout（布局）

解决“相对父容器放在哪儿”。父容器使用测量出的尺寸，调用 layout(left, top, right, bottom) 定位子 View。

• getMeasuredWidth()：来自 measure 阶段的测量期望结果。
• getWidth()：来自 layout 阶段的实际占位，计算公式为 right - left。 获取真实占位盒子大小，必须在 layout 之后调用 getWidth()。

阶段三：Draw（绘制）

解决“怎么画”。主线程的 onDraw 不直接操作 CPU 绘制像素，而是把 Canvas API 录制成 DisplayList，挂载到 RenderNode 上。局部 View 改变时，其他未改变节点的图纸直接重用。

四、常见场景与排障指南

1. 刷新机制：invalidate、requestLayout 与 postInvalidate

它们都不会立刻改变像素，而是向 Choreographer 注册下一个 VSYNC 的请求。

• invalidate()：视图内容变了（尺寸不变）。最终只重走 draw 阶段，更新局部的图纸。必须在主线程调用。
• postInvalidate()：作用等同于 invalidate()，但它是专门设计用于非主线程的。内部会通过 Handler 将刷新请求抛到主线程执行。
• requestLayout()：视图尺寸或结构变了。它会给当前节点打上 PFLAG_FORCE_LAYOUT 标记，触发完整的后序+先序遍历（measure -> layout -> draw）。

2. 获取尺寸：如何在 onCreate 里安全拿到 View 宽高？

在 onCreate 中直接调 getWidth() 为 0，因为此时还没等到 VSYNC 发令枪，尚未发生遍历。

• 正确做法：使用 View.post { }。
• 原理：Runnable 排在主线程消息队列后面，能保证在本轮遍历完成之后执行，此时宽高必定已经计算完毕。

3. 卡顿定位：主线程还是 GPU？

• 主线程过重：层级过深、过度使用 weight 导致重复测量、频繁触发 requestLayout，或在 onDraw 里进行了过多耗时操作（导致错过 16.6ms）。
• GPU 过度绘制 (Overdraw)：像素被多次无意义地覆盖，浪费填充合成成本。目标是消除开发者选项“调试 GPU 过度绘制”里的红色区域。

4. 自定义 View 开发最佳实践

• 避免在 onDraw() 中分配对象：动画期间会被频繁调用，new Paint() 会引发频繁 GC 导致卡顿。
• 妥善处理 wrap_content：直接继承 View 时如果不重写 onMeasure 处理 AT_MOST，wrap_content 会和 match_parent 一样大。应使用 resolveSize() 计算。
• 硬件加速退避：若复杂 Canvas 操作显示异常，可用 setLayerType(View.LAYER_TYPE_SOFTWARE, null) 让该 View 回退到 CPU 绘制。

5. 性能优化：多次测量（Double Taxation）与层级扁平化

• 问题本质：LinearLayout 的 weight 机制、RelativeLayout 的对齐关系会导致父容器在一轮 Measure 中对同一个子节点测量两次甚至多次。如果布局发生嵌套（比如多层 weight），测量次数会呈指数级爆炸，即所谓的**“性能双重税（Double Taxation）”**。
• 解法建议：优先使用 ConstraintLayout。它的设计初衷即通过建立约束系方程式，实现完全扁平化的视图层级，从根本上阻断了嵌套带来的指数级重复测量问题。

6. 线上排障：APM 如何监控 UI 卡顿（Jank）？

了解了 VSYNC 与渲染管线，就能明白业内主流 APM（如 BlockCanary、Matrix）监控卡顿的底层原理：

• 方案A：Looper.Printer 替换。主线程的所有操作最终都是 Handler 消息。替换 Looper.getMainLooper().setMessageLogging(printer)，记录每个 Message 处理的耗时，超过 16.6ms（或特定阈值）即判定为主线程卡顿。
• 方案B：Choreographer.FrameCallback。向 Choreographer 注册一个帧回调。由于回调总是在 VSYNC 唤醒时执行，通过计算两次回调的时间差，若远大于 16.6ms，即可精确计算出丢失了几个 VSYNC 周期（掉帧数）。

五、关联参考