浏览器：渲染管线

December 6, 2024December 12, 2024

chromium

Prerequisites

本节用于快速说明理解渲染所需的前置知识

全文以 Chromium/Blink 系为例

Caution

标准和规范是向后兼容的（Don't break the Web），但实现并非一成不变。
因此实现可能最终会过时，但思路是值得参考的。

多进程/线程模型

1 个浏览器进程
N 个 sandbox 渲染器进程（实现Site Isolation）
- 一个主线程：JavaScript（除了 worker）、DOM、CSS、样式和布局
- 多个工作线程：运行 Web Workers、ServiceWorker 和 Worklets
- 几个内部线程：处理 webaudio、数据库、GC
1 个 GPU 进程
1 个网络进程，实现网络堆栈
多个插件进程

浏览器与渲染器进程之间的通信是通过 Mojo 实现的

跨线程通信：基于 (blink) PostTask API 进行消息传递，很少共享内存

事件循环

事件循环决定如何在主线程上调度任务。任务是不可打断（暂停）的。

任务队列实际是特殊的优先队列，用于排队任务。

绘制一帧之前（某些任务导致 UI 变更），必须优先运行渲染步骤任务（Style→Layout→Paint）。

Render

渲染的终极目标是将标记语言/样式定义/脚本操作渲染为屏幕上的像素。

渲染管线中有很多中间态，使重渲染（更新）更高效。

解析 HTML 为 DOM
解析并处理样式表，计算出用于渲染的最终值（ComputedStyle），并将样式附加到对应 DOM
规则：级联（cascading）与继承
对于任一CSS属性：
初始值：每个属性有自己规范定义的初始值
声明值：所有应用到当前元素的属性值
级联值：根据级联规则得到的获胜声明
指定值：若存在级联值，则是级联值；否则根据继承规则得到
计算值：将指定值绝对化，为继承做准备（注意：此时没有进行布局，所以可能是auto）
应用值：（完成布局，得到可以用于渲染的绝对值）若计算值无效，则为空
实际值：实际渲染使用的值（此时可能考虑到物理设备做一些舍入）

层叠顺序（省略未实际实现的样式来源）：
过渡 → 作者样式!important → 动画 → 作者样式 → 用户代理样式
这一步的目标是根据 CSS 声明的布局，遵循 CSS 规范地计算出每个布局矩形的坐标和尺寸，最终生成一颗 LayoutTree

参见 blink 源码。另：在 blink 中我们称为 LayoutTree，某些文章会称为 RenderTree

每个 DOM 节点可能：
- 没有对应 LayoutObject：display:none
- 对应一个 LayoutObject：大部分情况
- 对应多个 LayoutObject：一个 LayoutObject 可以拥有块级子元素或内联子元素，但不能同时拥有两者。因此会生成匿名 LayoutObject 以满足规则。
  
  个人理解这里主要是为一组相连的内联盒子创建包含块。
  
  Note
  
  常规流：常规流中的盒子属于格式化上下文，可以是块级或内联级，但不能同时是两者。块级盒子参与块级格式化上下文，内联级盒子参与内联级格式化上下文。
遍历 LayoutTree，对 LayoutObject 进行布局操作：计算多种边界矩形的坐标（例如：若内容溢出，则需要计算滚动边界，滚动条等）
绘制 LayoutObject。遵循层叠（stacking）顺序。这一步实际上是记录一系列绘制指令
光栅化：Skia 将绘制指令转换为 OpenGL/vulkan 调用（把高层指令转换为底层指令），最终生成 bitmap
（GPU 进行光栅化，将生成的位图置于 GPU 内存，通过 OpenGL 纹理对象引用）

Dynamic Render

运行整个渲染管线来渲染帧是昂贵的。流水线的每个阶段跟踪细粒度的异步无效操作，尽可能的复用前一帧的中间态。（双缓冲）

如果一个大区域进行变换（例如滚动一个容器），绘制(Paint) + 光栅化(raster)操作仍然是昂贵的...
由于 JS 是阻塞且不可中断的，一切发生在主线程的操作还要与 JS 竞争。总之主线程是很繁忙的。

Tip

DevTools 的性能工具可用于分析任务

性能.png

主线程将页面分层（layer），层可以独立光栅化。每个合成器线程可独立绘制层，分担主线程压力

Warning

不要与层叠上下文混淆！

合成器线程可以（虽然并非总可以）处理浏览器线程的输入事件，而无需主线程参与

若用户输入会触发 DOM 已设置的监听器，则需要主线程来运行 JS，此时当然就不能只靠合成器线程处理了

题外话：
不过现代浏览器对此也有一些默认优化。例如对于 touchstart, touchmove, touchend, wheel（不含 scroll）事件（默认行为会产生滚动）它们在 Window Document 和 Document.body 上默认为 passive，即浏览器默认不等待监听器执行完毕

Related:
Using passive listeners
css touch-action
Smoother scrolling in Firefox 46 with APZ

根据什么规则分层？（参见此处 Blink 源码）

某些样式属性会触发布局对象生成一个层，特别是所有 3D 变换
可滚动区域需要生成多个层 overflow: scroll
某些替换元素会生成层 <video> <canvas>
要求浏览器生成层，例如 will-change: transform

Warning

z-index 控制的是层叠顺序，即 paint 的先后顺序，与 layer 没有直接关联。
一般来说，层（layer）也会创建自己的层叠上下文。毕竟它们都需要独立渲染了。（参见 blink 文档）
根据 blink 源码，静态（即非动画）2D transform 不会创建层。
既然不会创建层，可以说不会 GPU 加速。简单的方法是加上 translateZ(0)。
个人认为最佳实践是不要滥用 GPU 加速。可以认为现代浏览器对静态变换的优化是足够的，并且对动态变换（动画）已经做了 GPU 加速。
因此一般需要手动开启的场景为：非动画场景，且变换会经常发生

	position: absolute	transition :transform(<2d>)
渲染阶段	Layout	Composite
BFC	创建BFC	不创建BFC
创建层叠上下文	Yes	Yes
文档流	脱离文档流	保持在文档流中
定位参考	相对于最近的定位祖先元素	相对于元素自身

布局完成后，主线程将图层任务分配给多个合成器线程

具体来说，composer 向图层（layer）应用不同的属性（移动，缩放，裁剪，etc），构建一棵属性树

当所有 paint 工作完成后，主线程阻塞一段时间以接收所有合成器线程的层和属性树

图层可以很大，而视口可能只显示层的一部分，因此完整地光栅化整个层是昂贵的

合成器线程将层分割为图块（tiles），图块是光栅化的最小单元，越接近视口的图块优先级越高
合成器将图块加入（GPU）线程池来进行光栅化

Tip

DevTools 的渲染工具可以用于检查层和绘制

绘制.png

一旦所有图块都完成光栅化，合成线程就会生成绘制四边形（draw quads）
四边形类似于一个命令，用于在屏幕的特定位置绘制图块，同时需要考虑图层树应用的所有变换
每个四边形都会引用内存中对应图块的光栅化输出（此时像素还未显示在屏幕上）
这些四边形被封装在一个合成帧（compositor frame）对象中，然后提交给 GPU 进程

合成帧来自多个渲染器，也来自浏览器（浏览器有自己的用于UI的合成器
合成帧与表面（surface）相关联，表示它们将在屏幕上出现的位置
表面之间可以相互嵌入。浏览器UI可以嵌入渲染器。渲染器可以为跨源iframe嵌入其他渲染器
显示合成器在 GPU 进程的 Viz 合成线程上运行。它是 viz 服务（visuals 的简写）的一部分
显示合成器负责同步传入的帧，并理解嵌入表面之间的依赖关系（表面聚合）

在大多数平台上，显示合成器的输出是双缓冲的
图块绘制操作会绘制到后缓冲区，通过交换缓冲区来使其可见
最终，我们的像素显示在屏幕上了。:)

题外话

回流并重绘

下面我们使用这个简单的模型，而非完整的 Style→Layout→Pre-Paint→Paint→Layerize→Commit（主线程）流程

Render Steps Task.png

回流（reflow）是 Gecko（Firefox）术语。上文讨论 blink 时我们使用布局（layout）一词，但下文会按惯例使用“回流”。

正常情况下，浏览器每帧只需执行一次渲染步骤任务，称为正常回流。

当 JavaScript 代码路径强制浏览器以超出其通常节奏的方式执行回流过程时，称为强制回流。

例如，Element.getBoundingClientRect() 需要布局引擎同步获取元素精确坐标信息，浏览器必须立即回流（强制同步布局）以计算出当前帧（指即将生成的帧）的信息（不能使用上一帧）。
参见 blink 源码。立即回流就是运行 style 和 layout 步骤，但注意这些步骤本身也有优化策略。下面会提到如何防止破坏优化路径。

当代码路径在一帧内快速连续多次执行强制回流时，称为布局抖动。

参见：https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing
https://devhints.io/layout-thrashing

CSS 属性也可触发渲染步骤任务，见：https://csstriggers.com/

初次渲染时，通过静态 HTML 得到静态 DOM 结构，此时渲染是增量的：遍历渲染树时，可以根据固定的上下文布局得到当前节点布局。

每次 JavaScript 需要查询当前帧布局信息时，都必须回流。多次查询就会导致多次回流。

当（JavaScript 操作导致）DOM 变更时，若变动的渲染节点层级越高，则需要重新计算的子树也就越多；

反之，若渲染树没有变更，则回流可以使用上一次的布局信息（快速路径）。

若同时变更 DOM 并立即查询其布局，则需要立即回流，且回流必须完成重新布局。

这就揭示出优化策略：避免在一帧中多次变更 DOM 并查询布局，这会导致破坏布局快速路径（布局抖动）

const elements = [...document.querySelectorAll(".some-class")];

// Bad
for (const element of elements) {
    element.classList.add("width-adjust"); // invalidate Layout Tree
    element.getBoundingClientRect(); //   force a reflow
}

// Improved
const rects = elements.map((element) => element.getBoundingClientRect());
elements.forEach((element) => element.classList.add("width-adjust"));

// Bad
for (let i = 0; i < 10; i++) {
    elements[i].style.width = `${container.offsetWidth + 10}px`;
}

// Improved
const containerWidth = container.offsetWidth;
for (let i = 0; i < 10; i++) {
    elements[i].style.width = `${containerWidth + 10}px`;
}

或变更 DOM 后（通过 requestAnimationFrame）在下一帧读取其布局，避免强制回流。

React useLayoutEffect

这也是 React 的 useLayoutEffect 会影响性能的原因。它在提交 DOM 之前运行，阻塞当前帧渲染。

也可以使用 useEffect 或 ResizeObserver 来避免阻塞当前帧，但需要考虑布局偏移。

Warning

布局抖动（Layout Thrashing）是在一帧内发生的。而布局偏移（Layout Shift）是多次实际渲染导致的。
关于布局抖动，参见 INP 指标；关于布局偏移，参见 CLS 指标

tsx

let i = 0;

function MeasureExample() {
    console.log(++i); // => 1 2 3
    const [height, setHeight] = useState(0);

    const measuredRef = (node: HTMLElement) => {
        const observer = new ResizeObserver(([entry]) => {
            setHeight(entry.contentRect.height);
        });

        observer.observe(node);
        return () => observer.disconnect();
    };

    return (
        <>
            <h1 ref={measuredRef}>Hello, world ({i})</h1>
            <h2>The above header is {Math.round(height)}px tall</h2>
        </>
    );
}

requestAnimationFrame

/**
 * 通过 raf 调度的任务在 下一次重绘（帧）之前 运行
 */
declare function requestAnimationFrame(callback: FrameRequestCallback): number;

interface FrameRequestCallback {
    /** 当前所处主线程帧的开始时间 */
    (time: DOMHighResTimeStamp): void;
}

图片引用自：https://medium.com/@paul_irish/requestanimationframe-scheduling-for-nerds-9c57f7438ef4

MDN 上的说明目前比较简略，具体参见 HTML 标准 update the rendering 一节。

根据规范（run the animation frame callbacks），排队在同一帧的所有 raf 将会在实际调度 raf 阶段一口气同步执行。

举个例子：

html

<style>
    body {
        margin: 0;
        height: 100vh;
        background-size: 200% 200%;
        background-image: linear-gradient(135deg, #ff7c7c, #ffeb3b, #26c6da, #7e57c2);
        animation: glow 10s ease infinite;
        /* 背景颜色持续变化，因此浏览器会持续重绘 */
    }

    @keyframes glow {
        0%,
        100% {
            background-position: 0% 50%;
        }
        50% {
            background-position: 100% 50%;
        }
    }
</style>

<script>
    function loopRaf() {
        for (
            let i = 0;
            i < 50000; // 把这个值调大，效果更明显
            i++
        ) {
            requestAnimationFrame((currentFrame) => {
                console.log(currentFrame); // 当前帧开始时间，因此每次打印的值相同
                console.log(performance.now()); // 实际执行时间
            });
        }
    }

    setTimeout(loopRaf, 2000);
</script>

上例中，在同一帧中安排了非常多 raf，因为同一帧的所有 raf 会同步顺序执行，运行完后才能重绘，因此 raf 阶段会观测到明显卡顿。

当前帧排队的 raf 在下一帧之前运行，即当前帧的 ref 在当前帧运行。但 css 过渡则需要至少两帧才能过渡。
因此常见的模式是嵌套两个 raf：

const doubleRAF = (cb: () => unknown) => {
    requestAnimationFrame(() => requestAnimationFrame(() => cb()));
};

←Back to home

This work is licensed under CC BY-NC-SA 4.0