Chromium 渲染管线深度工程实战：从 DOM 到合成帧的全链路与 INP 优化

Chromium 渲染管线深度工程实战：从 DOM 到合成帧的全链路与 INP 优化

执行摘要：前端性能问题里最常见的误判，是把"卡"归因为"JS 跑得慢"。真实情况是：JS 只占了帧预算的一小段，真正吃掉的往往是样式重算范围失控、强制同步布局（forced synchronous layout）引发的读写交替、以及合成层爆炸导致的光栅化与内存回压。Chromium 把一帧拆成 12 个左右的阶段跑在四条线程上（主线程 / 合成器线程 / 光栅线程 / GPU 进程），每个阶段都有各自的失效规则。本文按渲染管线的真实顺序拆开 Blink 与 cc（Chromium Compositor）的分工，给出可复现的代码反例、Tracing 定位方法与一份生产级优化清单。理解这条管线后你会发现：绝大多数"优化"其实是在缩小失效范围，而不是让代码跑得更快。

一、一帧的账本：60Hz 下你只有 16.6ms

Chromium 的帧不是在主线程一口气画完的，而是流水线化的：

Main Thread:  Input → JS → Style → Layout → Paint(prepaint/paint) → Commit
Compositor:   Activate → Draw(raster tiles) → Submit
GPU Process:  Viz → SwapBuffer → 屏幕

关键点在于阶段之间是有状态的：Style 的输出是 ComputedStyle，Layout 的输出是 LayoutObject 树与 Fragment，Paint 的输出是一份 cc::DisplayItemList（显示列表），而不是像素。像素要到光栅线程才真正产生。这种"延迟物化"设计让滚动、transform、opacity 动画可以完全绕过主线程——前提是你没有破坏层的独立性。

帧预算不是固定 16.6ms。合成器会根据历史帧耗时估算一个 Deadline，主线程在 BeginFrame 之后必须在这个 Deadline 前把 commit 提交出去，否则这一帧就被丢弃（dropped frame），视觉上表现为掉帧。这就是 RenderingStats 里 DroppedFrameCount 的来源。

二、样式计算：失效范围是被低估的性能杀手

Blink 的样式引擎不是每次都全量重算。它维护了几套失效集合（descendant invalidation sets、sibling invalidation sets），当一条 CSS 规则的选择器右侧被 DOM 变化命中时，只把受影响的子树标脏。

/* 灾难写法：通用选择器让失效集合退化为"全集" */
.list * { color: var(--fg); }
/* 工程写法：把失效范围钉在具体类名上 */
.list__item { color: var(--fg); }

这里有个真实生产陷阱：CSS 自定义属性（CSS 变量）的失效粒度比普通属性粗。改动一个在 :root 上定义的变量，会让所有继承它的元素进入样式重算。很多"暗黑模式切换卡顿几百毫秒"的根因就在这里——正确的做法是把变量作用域下沉到组件根，切换时只让该子树失效。

另一个被忽视的点是选择器匹配顺序是从右到左。div ul li a 这类写法，引擎先找所有 a，再逐级向上验证祖先。Blink 为此给每个元素维护了祖先标签/类/id 的 Bloom filter，能在 O(1) 内排除绝大多数无效祖先链，但 Bloom filter 有假阳性，* 与后代选择器会让它彻底失效。

三、Layout NG：约束空间与"强制同步布局"

Layout NG 把布局建模成纯函数：Fragment = Layout(ConstraintSpace, InputNode)。这个设计的价值是布局可以被缓存和跳过——如果子树的约束空间没变、也没被标脏，就直接复用上次的 Fragment。

代价是：一旦你在 JS 里读取布局属性，引擎必须保证读到的是最新值，于是把挂起的布局强制刷新。这就是 forced synchronous layout。

// 反例：读写交替，N 次布局 + N 次样式重算（layout thrashing）
items.forEach(el => {
  const h = el.offsetHeight;      // 读：强制刷新布局
  el.style.height = h * 2 + 'px'; // 写：让下一次读失效
});

// 正例：先批量读，再批量写，只剩 1 次布局
const heights = items.map(el => el.offsetHeight);
requestAnimationFrame(() => {
  items.forEach((el, i) => { el.style.height = heights[i] * 2 + 'px'; });
});

这个改写没有让任何一行代码"变快"，它只是把 O(N) 次布局降成 O(1)。在 5000 个节点的列表上，这两段代码的差距可以是 800ms vs 12ms。

真正治本的手段是 CSS containment：

.card {
  contain: layout style paint;   /* 告诉引擎：这棵子树的布局/样式/绘制不外溢 */
}
.long-list > li {
  content-visibility: auto;      /* 视口外子树直接跳过 layout 与 paint */
  contain-intrinsic-size: 0 48px; /* 提供占位尺寸，避免滚动条抖动 */
}

contain: layout 让引擎确信子树的布局结果不会影响外界，从而把 layout 的失效边界切断；content-visibility: auto 更激进，直接跳过整个子树的 style/layout/paint，只保留一个占位框。这是长列表渲染从 O(总节点数) 降到 O(视口节点数) 的唯一原生手段，比任何虚拟滚动库都彻底，且不需要接管滚动行为。

四、Paint 与合成：层不是越多越好

Paint 阶段不画像素，只生成 DisplayItem 序列（绘制指令）。随后 cc 把可独立变换的内容提升为合成层（cc::Layer），每层被切成 256×256 的 tile 交由光栅线程并行处理。

层提升的触发条件包括 will-change: transform、transform: translateZ(0)、position: fixed、video/canvas 等。层的好处是动画可以由合成器线程独立完成，不受主线程阻塞；代价是：

• 每层一份 GPU 纹理，几百个层能吃掉上百 MB 显存；
• 层树变更会触发 raster invalidation，大面积重绘；
• 层过多会让 tile 数量爆炸，光栅线程排队，反而降低首屏速度。

/* 层爆炸：列表每一项都独立提升 */
.list__item { will-change: transform; }        /* 1000 项 = 1000 个层 */

/* 正确：只在真正需要动画的元素上使用，并且用完即弃 */
.list__item--dragging { will-change: transform; }

工程经验：will-change 应当是临时状态而非静态样式。静态声明等于向浏览器承诺"这玩意儿永远在动"，浏览器会常驻一个层，却拿不到任何收益。

五、INP：为什么"JS 不慢"但交互还是卡

INP（Interaction to Next Paint）衡量的是从用户输入到下一帧绘制完成的耗时，它由三段组成：输入延迟（Input Delay）、处理时长（Processing）、呈现延迟（Presentation）。大多数团队只盯第二段，实际上：

• 输入延迟：主线程被长任务占满，事件排队等不到执行；
• 呈现延迟：合成器在等光栅，或层树刚被大面积失效。

拆长任务的标准手段：

async function renderBatch(rows) {
  for (let i = 0; i < rows.length; i += 50) {
    renderChunk(rows.slice(i, i + 50));
    // 让出主线程，但保持比 setTimeout(0) 更高的调度优先级
    await scheduler.yield();
  }
}

scheduler.yield() 的语义是"让出但插回队首"，而 setTimeout(fn, 0) 会排到任务队列末尾，可能被其他任务插队 4ms 以上。在需要保持响应性的同时尽快完成工作时，这个差异很明显。

定位方法上，别用 console.time 猜。直接抓 Chrome Tracing（Performance 面板或 chrome://tracing），按以下顺序看：

六、一份可落地的检查清单

1. 先量化失效范围，再谈优化。Trace 里 UpdateLayoutTree 与 Layout 的耗时，直接对应你写法造成的失效面积。
2. 布局边界优先于算法优化。contain 与 content-visibility 的收益是数量级的，微优化是百分比级的。
3. 层是稀缺资源。把 will-change 当作运行时状态管理，而不是样式表的常驻属性。
4. 动画只用 transform 与 opacity。这两个属性可以全程留在合成器线程，其余属性都会把主线程拖回关键路径。
5. 长任务按 50ms 切片。这不是魔法数字，而是 INP 良好阈值（200ms）下留给输入延迟与呈现的余量。

七、结论

Chromium 渲染管线的核心矛盾只有一个：状态复用的收益 vs 失效范围的代价。Style 缓存、Layout NG 的约束空间、DisplayItem 缓存、合成层与 tile 缓存，全都是为了让绝大多数帧只做增量的事；而开发者写的每一行"方便"的代码——通配符选择器、读写交替、静态 will-change——都在扩大失效范围，把增量退化为全量。

所以判断一个前端团队是否真的懂性能，不看他们会不会用 memo、会不会摇树，而看他们能不能回答一个问题：这次改动会让多少节点进入样式重算。渲染管线的工程价值，恰恰在于它把"性能"这个含糊的词，翻译成了可以数清楚的失效节点数。