浏览器渲染管线：从字节到像素的全流程深度解析 - 简希博客

你每天写的 HTML/CSS/JS，浏览器到底是怎么把它变成屏幕上那些像素点的？大多数人只知道"DOM 树 + CSSOM 树 = 渲染树"，但这个说法粗糙到近乎误导。今天我们拆开 Chromium 的渲染管线，从网络层收到的第一个字节开始，一路追踪到 GPU 光栅化的最后一个像素。

一、字节流 → DOM：不只是"解析 HTML"

当网络层拿到 HTML 的第一个 chunk，解析器就开始工作。Chromium 的 HTML 解析器是基于状态机的（遵循 HTML5 规范的 tokenizer），而不是简单的正则或递归下降。

关键细节：

预扫描器（Preload Scanner）：在主解析器被 CSS/JS 阻塞时，预扫描器会快速扫过后续 token，提前发现需要预加载的资源（<link>, <script src>, <img> 等）。这是为什么把 <link rel="stylesheet"> 放在 <head> 里不会完全阻塞后续资源发现的原因。
脚本执行的三大阻塞规则：
- document.write 能直接往解析器输入流里注入 token —— 这是为什么它性能灾难的核心。
- 没有 async/defer 的 <script> 会触发 DOM 构建暂停，等 JS 执行完。
- CSS 不阻塞 DOM 构建，但阻塞 JS 执行（因为 JS 可能查询计算样式），间接阻塞 DOM。

<!-- 预扫描器能在 CSS 阻塞期间发现这些资源 -->
<link rel="stylesheet" href="app.css">
<!-- JS 必须等 CSS 加载完才能执行，但预扫描器已经发现了下面的 img -->
<script src="app.js"></script>
<img src="hero.jpg">  <!-- 预扫描器提前发起请求 -->

DOM 构建完成后，你得到的是一棵 C++ 对象树，不是 JS 里的 document 对象。JS 中的 DOM API 访问的是 Blink 为每个 DOM 节点创建的 wrapper 对象（通过 V8 的 BlinkGarbageCollected 绑定），两者之间有跨堆引用的开销。

二、CSS 解析：从文本到匹配规则

CSS 解析器将样式表转换为 StyleRule 对象列表，每条规则包含选择器和声明。重点来了——样式计算不是简单的"后来居上"。

级联算法的完整优先级排序：

来源优先级：用户代理 < 用户 < 作者 < 作者 !important < 用户 !important < 用户代理 !important
层叠层（Cascade Layers，@layer）：未分层 > @layer 由声明顺序决定
特异性（Specificity）：(a, b, c) 三元组，ID > 类/属性/伪类 > 元素/伪元素
出现顺序：同来源同特异性，后声明者胜

样式计算的输出：每个 DOM 节点获得一个 ComputedStyle 对象，包含 400+ 个 CSS 属性的计算值。这个过程会触发默认样式表（UA stylesheet）合并 → 作者样式匹配 → 用户样式覆盖 的三遍计算。

/* 这条规则虽然写在前，但特异性(0,1,0)高于下面的(0,0,1) */
.btn { color: red; }     /* (0,1,0) */
button { color: blue; }  /* (0,0,1) — 输给上面 */

三、布局（Layout）：从样式到几何

有了 ComputedStyle，下一步是计算每个节点的位置和尺寸。这就是布局阶段。

核心概念：格式化上下文

BFC（Block Formatting Context）：块级盒子的布局环境。触发条件：overflow: hidden、display: flow-root、浮动、绝对定位、inline-block 等。
IFC（Inline Formatting Context）：行内盒子的布局，涉及基线对齐、行盒（line box）计算。
FFC / GFC：Flex / Grid 格式化上下文，各有独立的布局算法。

包含块（Containing Block） 是布局的坐标系基准——绝对定位元素的 top/left 相对于最近的 position != static 祖先，而不是"父元素"。这是无数定位 Bug 的根源。

.container {
  position: relative;  /* 成为子元素绝对定位的包含块 */
}
.child {
  position: absolute;
  top: 0;  /* 相对于 .container 的 padding box 边缘 */
}

布局的性能陷阱：修改一个元素的几何属性（宽高、边距等）可能导致整个文档的布局重算——这就是"布局抖动（Layout Thrashing）"的由来。

// 🚫 强制同步布局 — 每次循环都读+写，触发 N 次完整布局
for (const el of elements) {
  const height = el.offsetHeight;  // 读 → 强制布局
  el.style.height = height * 2 + 'px';  // 写 → 使布局失效
}

// ✅ 先批量读，再批量写
const heights = elements.map(el => el.offsetHeight);  // 读 1 次
elements.forEach((el, i) => {
  el.style.height = heights[i] * 2 + 'px';  // 写 1 次
});

四、绘制（Paint）：生成绘制指令

布局完成后，浏览器知道每个元素的"样子"和"位置"，但还不会直接操作像素。Paint 阶段生成的是绘制指令列表（Display List / Paint Ops）——一堆类似"在此坐标画一个圆角矩形，填充色 #fff"的指令。

绘制顺序遵循 CSS 2.2 的层叠上下文规则：

背景和边框
负 z-index
块级盒子
浮动盒子
行内盒子
z-index: 0 / auto
正 z-index

每个层叠上下文形成一个独立的绘制组。这就是为什么 z-index 只在定位元素上生效——它创建的是层叠上下文，不是 z 轴坐标。

关键优化：Paint 阶段会利用 Display Item Caching —— 如果一个区域的绘制指令没变，可以直接复用上一次的结果，跳过重绘。

五、合成（Composite）：GPU 加速的核心

这是现代浏览器性能优化的主战场。

层的分裂：满足以下条件的元素会被提升为独立的合成层（Compositing Layer）：

will-change: transform / opacity
硬件加速的 CSS 动画（transform / opacity）
<video>, <canvas>, <iframe>
position: fixed
有 3D transform（translate3d, translateZ）

每个合成层有自己独立的纹理（Texture），由 GPU 独立光栅化。合成器（Compositor）只需在 GPU 上对纹理做变换（平移/缩放/旋转），就能实现动画——不需要经过主线程。

主线程:  JS → Style → Layout → Paint → Composite
                                      ↘
合成器线程:                         Composite → GPU 光栅化 → 绘制
                                                ↑ 独立运行，不阻塞主线程

transform 和 opacity 动画为什么性能好？ 因为它们只影响合成阶段——修改 transform 不会触发 Layout 和 Paint，直接在合成器线程完成。

/* ✅ 合成层动画：跳过 Layout + Paint，只触发 Composite */
.card:hover {
  transform: translateX(100px);  /* GPU 合成 */
  opacity: 0.8;                  /* GPU 合成 */
}

/* 🚫 触发完整管线：Layout → Paint → Composite */
.card:hover {
  left: 100px;      /* 触发 Layout */
  background: red;  /* 触发 Paint */
}

隐式合成层的陷阱：一个 z-index 较低的元素上方有合成层时，该元素也会被强制提升为合成层。页面合成层过多会导致 GPU 显存暴涨。

六、GPU 光栅化与显示

Chromium 从 M89 开始默认启用 GPU 光栅化（OOP Rasterization）：绘制指令直接在 GPU 进程中光栅化为瓦片（Tile），绕过 CPU 的 Skia 软件光栅化路径。

最终，合成器将所有合成层的纹理按正确顺序合成，通过 viz::CompositorFrame 提交给显示器。如果开启了 VSync，这一帧会在下一个 VSync 信号到来时上屏——这就是 60fps 的物理约束：每帧预算 ~16.67ms。

关键要点

渲染管线是流水线，不是单步：Style → Layout → Paint → Composite，每步都可能成为瓶颈，优化要针对性击破。
CSS 阻塞 JS 但不阻塞 DOM：CSS 加载期间 DOM 可以继续构建，但 JS 执行必须等 CSSOM 就绪。
布局抖动是性能杀手：读写交替强制同步布局，应批量读取后再批量写入。
transform/opacity 动画零成本：只触发合成，在 GPU 上完成，不经过主线程。
合成层不是越多越好：隐式提升和显存开销是真实代价，用 DevTools 的 Layers 面板监控层数。