六、Blink、V8 与 Renderer：网页代码如何变成可绘制的状态
俊宁 · 日期未详文章目录
从源码阅读入口、进程边界与验证条件理解Blink、V8 与 Renderer：网页代码如何变成可绘制的状态。
本文讨论通用机制和设计判断；示意不对应任何具体产品的已交付状态。源码阅读坐标沿用原稿，本次整理不构成新的运行时验收。
阅读坐标沿用原稿：Chromium
153.0.8010.37，上游 commitb75a5a95ea1a1b55bdbfd6d9f42d47be7507fb8b。本次同步未重新进行源码与目标平台运行时验收。
一句话结论
网页从 HTML/JavaScript 走到可绘制状态，要经过 Document 生命周期、V8/Blink binding、task 与 microtask、style/layout/paint 以及 compositor 共同推进的状态机，而非一条同步流水线。性能和正确性问题必须先定位发生在哪个阶段。
用户看到一个页面时，常把它理解成“HTML 被浏览器渲染了”。在 Renderer 内，这句话至少压缩了四套不同的工作：Blink 维护文档和 Web API 语义，V8 执行 JavaScript，style/layout 把 DOM 和 CSS 变成几何与可绘制对象，paint/compositing 再把变化提交给后续图形管线。它们共享 document 生命周期，却不是一条永远同步、从上到下只走一次的流水线。
阅读这部分源码，先区分三种变化：DOM 变了、几何变了、可绘制内容变了。 一次 JavaScript 修改可能只影响其中一种，也可能在随后某个时点让三种变化同时发生。
Renderer 里的四个协作角色
| 角色 | 主要职责 | 典型误解 |
|---|---|---|
| Blink DOM / Web API | Document、Node、Frame、事件、HTML/CSS/Web API 的浏览器侧实现 | DOM 是 JavaScript 对象的简单镜像 |
| V8 | JavaScript 执行、heap、GC、microtask 与绑定调用 | 所有页面行为都由 V8 单独决定 |
| Style / Layout | 选择器匹配、computed style、布局树、尺寸与位置计算 | 改一个 DOM 节点一定重新 layout 整页 |
| Paint / Compositing | paint property、display item、layer 与 frame 提交的渲染侧输入 | paint 完成就已经显示在屏幕上 |
Browser 进程负责导航、权限、Profile 和产品策略；Renderer 负责已提交 document 内的 Web 内容执行。这个界线非常重要：当问题发生在“页面还没拿到 response”或“导航被策略拒绝”时，先去 Blink/V8 搜索通常会走错方向；当问题是某段脚本、DOM 生命周期或 style invalidation 时，才应该进入 Renderer。
从 HTML 到 Document，不等于从字符串到像素
页面内容抵达 Renderer 后，Blink 会在 Frame/Document 语境中处理文档加载与解析。解析过程逐步创建 DOM 节点，脚本、样式表、子资源和事件又会反过来影响 document 的推进时机。HTML parser 不是脱离页面生命周期独立跑完的函数；脚本可能阻塞或重入，document 也可能在导航、frame 销毁或错误处理时提前结束。
所以阅读一次页面加载时，至少要将以下对象分开：
Frame：页面嵌入关系和浏览上下文的一部分
Document：当前已提交页面的 DOM、URL、生命周期和执行环境
DOM tree：节点与属性的结构
Style / Layout tree：为计算和绘制建立的派生结构
它们相关但不等价。一个 DOM Node 不保证拥有 layout object；隐藏、未连接或尚未进入需要布局阶段的节点都可能没有可用几何信息。反过来，layout 和 paint 的结果也可能因样式或合成策略改变，而不对应一个“新 DOM”。
V8 与 Blink 的交接：绑定不是普通函数调用
JavaScript 运行在 V8 isolate 与 context 中，但 DOM、Fetch、Storage、事件等 Web API 的大部分浏览器语义由 Blink 提供。IDL 和绑定生成代码让页面脚本能够调用这些 API；从 JavaScript 看像 element.appendChild()，从实现看会跨过 V8 binding、Blink C++ 对象、Web IDL 的类型/异常/生命周期规则。
这意味着排查 Web API 问题时通常要沿三层读：
- Web IDL 或 Web API 定义：页面能看见怎样的签名、权限和异常；
- generated binding：参数如何转换、对象如何包装、异常和 promise 如何回到 JS；
- Blink 实现：真正改变 Document、Node、style、网络请求或 IPC 的业务逻辑。
只看 V8 的 JavaScript 栈，容易遗漏 Blink 的生命周期校验；只看 Blink C++，又可能忽略 promise/microtask 让回调延后到了不同任务边界。对于异步 API，必须同时记录“promise 何时创建”和“resolve/reject 在什么 document/frame 状态下发生”。
任务、microtask 与“为什么顺序和直觉不同”
Renderer 的事件循环并不是执行一段 JS 后立刻把所有视觉结果同步呈现。用户输入、network completion、timer、postMessage、animation、script task 等会以不同任务来源进入；promise continuation 等 microtask 又在特定检查点执行。Blink 的 lifecycle update、style/layout/paint 也会受 frame、调度和是否需要更新影响。
不必把所有调度细节背下来，但阅读代码时要避免两个错误推论：
- “调用
setTimeout、promise 或 IPC callback 后，下一行一定发生视觉更新。” - “一次 DOM mutation 返回后，layout 和 paint 已经完成。”
更准确的写法是：DOM mutation 让相关状态失效；后续在合适的生命周期更新中，style/layout/paint 可能被计算并提交。若脚本主动读取依赖几何的信息，浏览器可能需要在此时保证所需计算可用；这种强制同步工作也是页面卡顿分析的重要线索，不能简单归为“浏览器慢”。
Style、Layout 与 Paint：三种不同成本
| 变化类型 | 可能影响 | 阅读和性能分析时要验证 |
|---|---|---|
| DOM / style invalidation | 选择器匹配与 computed style | 哪些节点被标记、是否扩散到祖先/后代 |
| Layout invalidation | 尺寸、位置、line box、滚动几何 | 是否必须重算子树或更大范围 |
| Paint invalidation | 可视内容、display item、raster 输入 | 是否只重绘局部，还是改变合成边界 |
这些不是严格的一对一映射。某些 CSS 属性只影响绘制，有些会影响布局；同一视觉效果也可能因 layer/compositing 策略而走不同路径。文章、代码评审和性能优化都应避免承诺“改这个属性一定只 repaint”之类的绝对结论，除非已在目标版本、目标平台和实际 trace 中验证。
生命周期比函数名更重要
Blink 里大量对象与当前 Document 或 Frame 绑定。导航提交后旧 document 会进入销毁流程，Frame 也可能被移除；此时异步任务、event listener、script callback 和 C++ wrapper 都必须避免向旧上下文继续写入结果。
因此读一个 Renderer bug 时，除了找调用函数，还要明确它位于何种生命周期：
- 页面正在解析、loading、interactive 还是已完成？
- 当前 callback 是否仍属于同一个 Document/LocalFrame？
- navigation、BFCache、iframe removal 或 renderer crash 是否会使它失效？
- 脚本能否在 observer/event 中重入，改变原先假定的 DOM？
这类问题常被误判为“异步时序偶现”。更准确地说，它们是 document ownership 与取消语义没有被表达或验证。
怎样追一条真实的 Renderer 路径
以“脚本修改一个元素的 class，页面在下一帧发生视觉变化”为例，建议分四轮追踪：
- 从 Web API/IDL 和 binding 找到 DOM mutation 的 Blink 实现，确认它修改了什么对象。
- 记录产生的 invalidation：是 style、layout、paint，还是三者的组合；不要用结果猜原因。
- 在 DevTools Performance、Tracing 或相关 debug instrumentation 中验证 lifecycle update 与 frame 的时序。
- 沿 Renderer 的 paint/compositor 输出继续追到 Viz/GPU 路径，确认“提交给合成器”与“显示到屏幕”分别在哪里完成。
每轮都可以停下来验证。若第二轮无法确定 invalidation，就不应提前从“改 class”推导出“必然 layout”；若第四轮只看到 Browser UI 的 repaint，也不能反推页面 Renderer 的计算已经发生。
源码验证路径
- 在基线 checkout 中选一个 DOM API，登记 Web IDL、generated binding 与 Blink C++ 实现三层入口。
- 选一条 DOM mutation，使用 trace 或 DevTools Performance 记录 style/layout/paint 的实际时序与范围。
- 对 promise/microtask、timer 和 navigation cancellation 各做一个小页面，观察 callback 的 document/frame 生命周期约束。
工程推演：一次 DOM 更新为何可能造成长帧
假设 Agent 结果流式写入页面或侧边栏：每次 token 都修改 DOM，脚本随后立即读取几何信息，再继续写 style。问题并不在“字符串很多”，而在 write/read 交替可能反复强制 style 与 layout；若节点还触发大范围 paint 或主线程 JavaScript 长任务，就会把多个成本压进同一帧预算。
正确排查顺序是把一次用户可见卡顿拆开：JavaScript task 是否过长，microtask 是否形成饥饿，style invalidation 覆盖哪些节点，layout 是否被同步读取触发，paint record 与 raster 是否扩大，最后 compositor 是否及时 submit/present。DevTools Performance 和 Chromium trace 的价值，正是把这些阶段放在同一时间轴，而不是给出一个笼统的“渲染慢”。
优化也应对症：合并 DOM write、把 read 集中到布局稳定后、减少无关 subtree invalidation、对纯视觉变化优先使用 compositor-friendly 属性、为流式结果设置批次与背压。把工作移到 requestAnimationFrame 只改变调度时机，不会自动减少实际计算量；把 JavaScript 移入 worker 也无法直接执行 DOM/layout。
Document 生命周期比 DOM 树更能解释问题
同一个 WebContents 中，导航会创建、提交并替换 document；BFCache 还可能让旧 document 进入冻结状态，之后恢复。页面对象仍存在不代表它当前可见或允许继续执行，frame token 也不能替代 document identity。
这对异步 Web API、content script 和 Browser reply 很重要。一个请求在旧 document 发出，返回时 Tab 和 frame 可能仍存在，但当前 document 已经不同。Renderer 侧应依赖与请求绑定的 execution context/document 状态，Browser 侧则需要携带足够的 frame/document identity，而不是只比较 URL。
生命周期至少要区分 active、hidden、frozen、in BFCache、detached 和 destroyed。计时器、网络、媒体、Observer 与 injected script 在这些状态下的允许行为不同；“页面没有关闭”不是继续工作的充分条件。
Event loop：脚本顺序为什么和调用栈直觉不同
一次 JavaScript callback 结束后，microtask checkpoint、渲染机会、其他 task source 和 Browser IPC reply 可能交错。Promise 连续排入 microtask 会延迟 rendering opportunity；长 task 会同时推迟输入、layout 和 frame production；同步读取布局属性又可能迫使 Blink 提前完成 style/layout。
分析顺序问题时，应把事件写成时间线，而不是只看源代码上下排列：
task: input handler
-> DOM mutation
-> schedule promise microtask
-> synchronous layout read
microtask checkpoint
-> another DOM mutation
rendering opportunity
-> style / layout / pre-paint / paint
-> compositor commit
UI 偶发落后一帧时，callback 可能已经执行，但结果在本帧 lifecycle cutoff 之后才到达；输入卡顿也可能来自 microtask 或强制 layout 持续占住主线程，不能直接归因于 GPU 性能。
Style、Layout、Paint 与 Composite 应分别优化
四个阶段的成本来源不同：
| 阶段 | 常见扩大因素 | 主要证据 |
|---|---|---|
| Style | 选择器匹配范围、继承、样式失效扩散 | Blink/DevTools style invalidation、主线程 trace |
| Layout | 几何依赖、同步读写交错、大范围 reflow | layout event、affected nodes、long task |
| Paint | display item/paint chunk 变化、复杂效果、大面积损坏 | paint invalidation、record time、paint artifact |
| Composite/Raster | layer 数量、tile、纹理上传、GPU/软件后端 | compositor/Viz/GPU trace、frame timeline |
“使用 transform 就一定不卡”也是过度概括。它可能避免部分 layout/paint，却会增加 layer、纹理和合成成本；低端 GPU、超大 surface 或频繁上传时仍可能掉帧。应先确定瓶颈阶段，再决定移动工作还是减少工作。
Worker、Worklet 与 Offscreen 不会自动消除主线程成本
把计算移到 Worker 能减少主线程 JavaScript，但 DOM、许多 Web API 和最终 UI commit 仍需回到主线程。数据在 worker 间 structured clone 或转移也有成本；消息频率和 ownership 不清晰时，会从“长任务”变成“消息风暴”。
同样，compositor thread 能独立推进部分动画，不代表所有视觉变化都绕开 main thread。动画属性、layout 依赖、paint invalidation 和资源 ready 状态决定它是否真的在 compositor-only path。源码阅读需要找到 property tree 和 animation eligibility 的实际判断，而不是凭 CSS 属性名推断。
用一个 AI 页面场景串起 Renderer 证据
假设内置 Extension 在页面侧提取选区，异步调用 Agent，再把结果渲染到浮层。应分别记录：选区属于哪个 document，content script execution context 是否仍 active，请求 payload 是否跨过 Browser 权限边界，reply 到达时 document 是否仍相同，DOM 更新触发了哪些 style/layout/paint，以及浮层是否在预期 frame present。
复现“结果偶尔出现在错误页面”时，优先验证 document/request identity；复现“结果出现但页面卡住”时，查看 payload 处理、DOM 批量更新、强制 layout 和 frame timeline。两种症状可能来自同一功能，却属于不同 owner，不能用一个 debounce 同时修复。
工程结论
Renderer 性能问题需要从状态失效范围和帧生命周期解释。知道某个 API 最终落到哪个 C++ 类只是入口；能说明它创建了什么 task、改变了哪类状态、使哪些节点失效、何时进入下一帧，才足以支持修复。
继续阅读
- 07-导航、Network Service 与缓存：URL 如何成为一个已提交的页面: 相邻章节的后续机制。
上游源码入口
文中的相对源码路径可从 Chromium 官方上游快照 定位。此入口保留原稿的上游阅读坐标，不包含任何产品定制代码，也不替代运行时验收。