Blink 工作原理

October 27, 2024

翻译自：http://bit.ly/how-blink-works

Blink 工作原理

Blink 的开发工作并非易事。对于 Blink 新手开发者而言，Blink 引入了许多特有的概念和编码规范，旨在实现一个极速的渲染引擎，这需要一定的学习成本。即使是经验丰富的 Blink 开发者，由于 Blink 体量庞大，并且对性能、内存和安全极其敏感，开发工作也充满挑战。

本文旨在从宏观角度概述 Blink 的工作原理，希望能帮助 Blink 开发者快速熟悉其架构：

本文并非 Blink 详细架构和编码规则的完整教程（这些规则可能会发生变化，并很快过时）。相反，本文将简明扼要地描述 Blink 的基本原理，这些原理在短期内不太可能发生变化，并指出你可以阅读的资源，以便更深入地学习。
本文不会解释具体的功能（e.g., ServiceWorkers, editing）。而是解释一些代码库中广泛使用的基础功能（e.g., 内存管理、V8 API）。

有关 Blink 开发的更多常规信息，请参阅 Chromium wiki 页面。

Blink 的功能

Blink 是 Web 平台的渲染引擎。概括地说，Blink 实现了浏览器选项卡内所有内容的渲染：

实现 Web 平台规范（例如，HTML 标准），包括 DOM、CSS 和 Web IDL
嵌入 V8 并运行 JavaScript
从底层网络栈请求资源
构建 DOM 树
计算样式和布局
嵌入 Chrome 合成器并绘制图形

许多客户端（例如 Chromium、Android WebView 和 Opera）都通过 content public APIs 嵌入了 Blink。

从代码库的角度来看，“Blink”通常指 //third_party/blink/。从项目的角度来看，“Blink”通常指实现 Web 平台功能的项目。实现 Web 平台功能的代码涵盖了 //third_party/blink/、//content/renderer/、//content/browser/ 和其他位置。

进程/线程架构

进程

Chromium 采用多进程架构。Chromium 有一个浏览器进程和 N 个沙盒化的渲染器进程。Blink 运行在渲染器进程中。

渲染器进程是如何创建的？出于安全考虑，在跨站点文档之间隔离内存地址区域至关重要（这称为站点隔离）。理论上，每个渲染器进程最多只能专用于一个站点。然而，实际上，当用户打开过多的选项卡或设备没有足够的内存时，将每个渲染器进程限制在一个站点有时会占用过多的资源。这时，一个渲染器进程可能会被来自不同站点的多个 iframe 或选项卡共享。这意味着一个选项卡中的 iframe 可能由不同的渲染器进程托管，而不同选项卡中的 iframe 可能由同一个渲染器进程托管。渲染器进程、iframe 和选项卡之间不存在 1:1 的映射关系。

由于渲染器进程在沙盒中运行，Blink 需要请求浏览器进程来分派系统调用（例如，文件访问、播放音频）和访问用户配置文件数据（例如，Cookie、密码）。这种浏览器与渲染器进程之间的通信是通过 Mojo 实现的。（注意：过去我们使用的是 Chromium IPC，并且许多地方仍在使用它。但是，它已被弃用，并在底层使用了 Mojo）在 Chromium 方面，服务化正在进行中，并将浏览器进程抽象为一组“服务”。从 Blink 的角度来看，Blink 可以直接使用 Mojo 与服务和浏览器进程进行交互。

如果你想了解更多信息：

多进程架构
Blink 中的 Mojo 编程：platform/mojo/MojoProgrammingInBlink.md

线程

一个渲染器进程中会创建多少个线程？

Blink 有一个主线程、N 个工作线程和几个内部线程。

几乎所有重要的事情都发生在主线程上。所有 JavaScript（除了 worker）、DOM、CSS、样式和布局计算都在主线程上运行。Blink 经过高度优化，可以在假设大多是单线程架构的情况下最大限度地提高主线程的性能。

Blink 可以创建多个工作线程来运行 Web Workers、ServiceWorker 和 Worklets。

Blink 和 V8 可能会创建几个内部线程来处理 webaudio、数据库、GC 等。

对于跨线程通信，你必须使用 PostTask API 进行消息传递。不鼓励使用共享内存编程，除非某些地方确实需要出于性能原因使用它。这就是为什么你在 Blink 代码库中看不到很多 MutexLocks 的原因。

如果你想了解更多信息：

Blink 中的线程编程：platform/wtf/ThreadProgrammingInBlink.md
Workers：core/workers/README.md

Blink 的初始化和终止

Blink 通过 BlinkInitializer::Initialize() 初始化。在执行任何 Blink 代码之前，必须调用此方法。

另一方面，Blink 永远不会被终止；也就是说，渲染器进程会被强制退出而不会被清理。其中一个原因是性能。另一个原因是，通常很难以优雅有序的方式清理渲染器进程中的所有内容（而且这样做不值得）。

目录结构

Content public APIs 和 Blink public APIs

Content public APIs 是使嵌入器能够嵌入渲染引擎的 API 层。Content public APIs 必须仔细维护，因为它们暴露给嵌入器。

Blink public APIs 是将 //third_party/blink/ 中的功能暴露给 Chromium 的 API 层。该 API 层只是从 WebKit 继承的历史遗留物。在 WebKit 时代，Chromium 和 Safari 共享 WebKit 的实现，因此需要 API 层将 WebKit 的功能暴露给 Chromium 和 Safari。现在 Chromium 是 //third_party/blink/ 的唯一嵌入器，API 层已经没有意义了。我们正在积极减少 Blink public APIs 的数量，方法是将 Web 平台代码从 Chromium 移至 Blink（该项目称为 Onion Soup）。

目录结构和依赖关系

//third_party/blink/ 包含以下目录。有关这些目录的更详细定义，请参阅此文档：

platform/
- Blink 底层功能的集合，这些功能是从单体 core/ 中分离出来的。例如，几何和图形实用程序。
core/ 和 modules/
- 规范中定义的所有 Web 平台功能的实现。core/ 实现与 DOM 紧密耦合的功能。modules/ 实现更独立的功能。例如 webaudio、indexeddb。
bindings/core/ 和 bindings/modules/
- 从概念上讲，bindings/core/ 是 core/ 的一部分，bindings/modules/ 是 modules/ 的一部分。大量使用 V8 API 的文件放在 bindings/{core,modules} 中。
controller/
- 一组使用 core/ 和 modules/ 的高级库。例如，devtools 前端。

依赖关系按以下顺序流动：

Chromium => controller/ => modules/ 和 bindings/modules/ => core/ 和 bindings/core/ => platform/ => 低级原语，例如 //base、//v8 和 //cc

Blink 仔细维护暴露给 //third_party/blink/ 的低级原语列表。

如果你想了解更多信息：

目录结构和依赖关系：blink/renderer/README.md

WTF

WTF 是一个“Blink 特定的基础”库，位于 platform/wtf/。我们正试图尽可能地统一 Chromium 和 Blink 之间的编码原语，因此 WTF 应该很小。需要这个库是因为有许多类型、容器和宏确实需要针对 Blink 的工作负载和 Oilpan（Blink GC）进行优化。如果类型是在 WTF 中定义的，则 Blink 必须使用 WTF 类型而不是在 //base 或 std 库中定义的类型。最常用的类型是向量、哈希集、哈希映射和字符串。Blink 应使用 WTF::Vector、WTF::HashSet、WTF::HashMap、WTF::String 和 WTF::AtomicString，而不是 std::vector、std::*set、std::*map 和 std::string。

如果你想了解更多信息：

如何使用 WTF：platform/wtf/README.md

内存管理

就 Blink 而言，你需要注意三种内存分配器：

PartitionAlloc
Oil Pan （又名 Blink GC）
malloc/free 或 new/delete（已禁用）

你可以使用 USING_FAST_MALLOC() 在 PartitionAlloc 的堆上分配对象：

c++

class SomeObject {
  USING_FAST_MALLOC(SomeObject);
  static std::unique_ptr<SomeObject> Create() {
    return std::make_unique<SomeObject>();  // 在 PartitionAlloc 的堆上分配
  }
};

由 PartitionAlloc 分配的对象的生命周期应由 scoped_refptr<> 或 std::unique_ptr<> 管理。强烈建议不要手动管理生命周期。Blink 中禁止手动删除。

你可以使用 GarbageCollected 在 Oilpan 的堆上分配对象：

c++

class SomeObject : public GarbageCollected<SomeObject> {
  static SomeObject* Create() {
    return new SomeObject;  // 在 Oilpan 的堆上分配
  }
};

由 Oilpan 分配的对象的生命周期由垃圾收集器自动管理。你必须使用特殊指针（例如，Member<>、Persistent<>）来持有 Oilpan 堆上的对象。请参阅此 API 参考以熟悉有关 Oilpan 的编程限制。最重要的限制是，你不允许在 Oilpan 对象的析构函数中触及任何其他 Oilpan 对象（因为不能保证销毁顺序）。

如果你既不使用 USING_FAST_MALLOC() 也不使用 GarbageCollected，则对象将在系统 malloc 的堆上分配。强烈建议不要在 Blink 中这样做。所有 Blink 对象都应由 PartitionAlloc 或 Oilpan 分配，如下所示：

默认使用 Oilpan。
仅当 1）对象的生命周期非常清晰并且 std::unique_ptr<> 或 scoped_refptr<> 足够时，2）在 Oilpan 上分配对象会引入很多复杂性时，或者 3）在 Oilpan 上分配对象会给垃圾收集运行时带来很多不必要的压力时，才使用 PartitionAlloc。

无论你使用 PartitionAlloc 还是 Oilpan，都必须非常小心，不要创建悬空指针（注意：强烈建议不要使用原始指针）或内存泄漏。

如果你想了解更多信息：

如何使用 PartitionAlloc：platform/wtf/allocator/Allocator.md
如何使用 Oilpan：platform/heap/BlinkGCAPIReference.md
Oilpan GC 设计：platform/heap/BlinkGCDesign.md

任务调度

为了提高渲染引擎的响应速度，Blink 中的任务应尽可能异步执行。不鼓励使用同步 IPC/Mojo 和任何其他可能需要几毫秒的操作（尽管有些是不可避免的，例如用户的 JavaScript 执行）。

渲染器进程中的所有任务都应使用正确的任务类型发布到 Blink 调度器，如下所示：

c++

// 使用 kNetworking 的任务类型将任务发布到帧的调度器
frame->GetTaskRunner(TaskType::kNetworking)->PostTask(..., WTF::Bind(&Function));

Blink 调度器维护多个任务队列，并智能地确定任务的优先级，以最大限度地提高用户感知的性能。指定正确的任务类型非常重要，这样 Blink 调度器才能正确且智能地调度任务。

如果你想了解更多信息：

如何发布任务：third_party/blink/renderer/platform/scheduler/TaskSchedulingInBlink.md

页面、框架、文档、DOMWindow 等

概念

页面（Page）、框架（Frame）、文档（Document）、ExecutionContext 和 DOMWindow 是以下概念：

页面对应于选项卡的概念（如果没有启用下文解释的 OOPIF）。每个渲染器进程可能包含多个选项卡。
框架对应于框架的概念（主框架或 iframe）。每个页面可能包含一个或多个按树状层次结构排列的框架。
DOMWindow 对应于 JavaScript 中的 window 对象。每个框架都有一个 DOMWindow。
文档对应于 JavaScript 中的 window.document 对象。每个框架都有一个文档。
ExecutionContext 是一个抽象文档（对于主线程）和 WorkerGlobalScope（对于工作线程）的概念。

渲染器进程：Page = 1：N。

Page：Frame = 1：M。

Frame：DOMWindow：Document（或 ExecutionContext）= 1：1：1 在任何时间点，但映射可能会随着时间而改变。例如，考虑以下代码：

javascript

iframe.contentWindow.location.href = "https://example.com";

在这种情况下，将为 https://example.com 创建一个新的 DOMWindow 和一个新的文档。但是，可以重复使用该框架。

（注意：准确地说，在某些情况下会创建一个新文档，但会重复使用 DOMWindow 和框架。还有更复杂的情况）

如果你想了解更多信息：

core/frame/FrameLifecycle.md

进程外 iframe (OOPIF)

站点隔离使事情更安全，但也更复杂。:) 站点隔离的思想是每个站点创建一个渲染器进程。（站点是页面的可注册域 + 1 个标签及其 URL 方案。例如，https://mail.example.com 和 https://chat.example.com 位于同一站点，但 https://noodles.com 和 https://pumpkins.com 不位于同一站点）如果一个页面包含一个跨站点 iframe，则该页面可能由两个渲染器进程托管。考虑以下页面：

html

<!-- https://example.com -->
<body>
    <iframe src="https://example2.com"></iframe>
</body>

主框架和 <iframe> 可能由不同的渲染器进程托管。渲染器进程本地的框架由 LocalFrame 表示，而非渲染器进程本地的框架由 RemoteFrame 表示。

从主框架的角度来看，主框架是一个 LocalFrame，而 <iframe> 是一个 RemoteFrame。从 <iframe> 的角度来看，主框架是一个 RemoteFrame，而 <iframe> 是一个 LocalFrame。

LocalFrame 和 RemoteFrame（可能存在于不同的渲染器进程中）之间的通信通过浏览器进程处理。

如果你想了解更多信息：

设计文档：站点隔离设计文档
如何使用站点隔离编写代码：core/frame/SiteIsolation.md

分离的框架/文档

框架/文档可能处于分离状态。考虑以下情况：

javascript

doc = iframe.contentDocument;
iframe.remove(); // iframe 从 DOM 树中分离
doc.createElement("div"); // 但是你仍然可以在分离的框架上运行脚本

棘手的事实是，你仍然可以在分离的框架上运行脚本或 DOM 操作。由于框架已被分离，大多数 DOM 操作将失败并引发错误。不幸的是，分离框架的行为在浏览器之间并没有真正的互操作性，在规范中也没有明确定义。基本上，期望是 JavaScript 应该继续运行，但大多数 DOM 操作应该失败并抛出一些适当的异常，如下所示：

c++

void someDOMOperation(...) {
  if (!script_state_->ContextIsValid()) { // 框架已分离
    …;  // 设置异常等
    return;
  }
}

这意味着在通常情况下，当框架分离时，Blink 需要执行许多清理操作。你可以通过继承 ContextLifecycleObserver 来做到这一点，如下所示：

c++

class SomeObject : public GarbageCollected<SomeObject>, public ContextLifecycleObserver {
  void ContextDestroyed() override {
    // 在这里执行清理操作
  }
  ~SomeObject() {
    // 在这里执行清理操作不是一个好主意，因为这已经太晚了。此外，析构函数不允许触及 Oilpan 堆上的任何其他对象
  }
};

Web IDL 绑定

当 JavaScript 访问 node.firstChild 时，将调用 node.h 中的 Node::firstChild()。它是如何工作的？让我们来看看 node.firstChild 是如何工作的。

首先，你需要根据规范定义一个 IDL 文件：

node.idl

interface Node : EventTarget {
  [...] readonly attribute Node? firstChild;
};

Web IDL 的语法在 Web IDL 规范中定义。[...] 称为 IDL 扩展属性。一些 IDL 扩展属性在 Web IDL 规范中定义，其他是 Blink 特定的 IDL 扩展属性。除了 Blink 特定的 IDL 扩展属性外，IDL 文件应以符合规范的方式编写（即，只需从规范中复制和粘贴）。

其次，你需要为 Node 定义一个 C++ 类并为 firstChild 实现一个 C++ getter：

c++

class EventTarget : public ScriptWrappable {  // 所有暴露给 JavaScript 的类都必须继承自 ScriptWrappable
  ...;
};

class Node : public EventTarget {
  DEFINE_WRAPPERTYPEINFO();  // 所有具有 IDL 文件的类都必须具有此宏
  Node* firstChild() const { return first_child_; }
};

通常情况下，就是这样。当你构建 node.idl 时，IDL 编译器会自动为 Node 接口和 Node.firstChild 生成 Blink-V8 绑定。自动生成的绑定在 //src/out/{Debug,Release}/gen/third_party/blink/renderer/bindings/core/v8/v8_node.h 中生成。当 JavaScript 调用 node.firstChild 时，V8 调用 v8_node.h 中的 V8Node::firstChildAttributeGetterCallback()，然后调用你在上面定义的 Node::firstChild()。

如果你想了解更多信息：

如何添加 Web IDL 绑定：bindings/IDLCompiler.md
如何使用 IDL 扩展属性：bindings/IDLExtendedAttributes.md
规范：Web IDL 规范

V8 和 Blink

Isolate、Context、World

当你编写涉及 V8 API 的代码时，了解 Isolate、Context 和 World 的概念非常重要。它们在代码库中分别由 v8::Isolate、v8::Context 和 DOMWrapperWorld 表示。

Isolate 对应于一个物理线程。Blink 中的 Isolate：物理线程 = 1：1。主线程有自己的 Isolate。工作线程有自己的 Isolate。

Context 对应于一个全局对象（在 Frame 的情况下，它是 Frame 的 window 对象）。由于每个框架都有自己的 window 对象，因此一个渲染器进程中有多个 Context。当你调用 V8 API 时，必须确保你位于正确的上下文中。否则，v8::Isolate::GetCurrentContext() 将返回错误的上下文，在最坏的情况下，最终会导致对象泄漏并导致安全问题。

World 是一个支持 Chrome 扩展程序的内容脚本的概念。World 不对应于 Web 标准中的任何内容。内容脚本希望与网页共享 DOM，但出于安全原因，内容脚本的 JavaScript 对象必须与网页的 JavaScript 堆隔离。（此外，一个内容脚本的 JavaScript 堆必须与另一个内容脚本的 JavaScript 堆隔离）为了实现隔离，主线程为网页创建一个主 World，并为每个内容脚本创建一个隔离的 World。主 World 和隔离的 World 可以访问相同的 C++ DOM 对象，但它们的 JavaScript 对象是隔离的。这种隔离是通过为一个 C++ DOM 对象创建多个 V8 包装器来实现的；即，每个 World 一个 V8 包装器。

Context、World 和 Frame 之间的关系是什么？

假设主线程上有 N 个 World（一个主 World + (N - 1) 个隔离的 World）。那么一个 Frame 应该有 N 个 window 对象，每个 window 对象用于一个 World。Context 是对应于 window 对象的概念。这意味着当我们有 M 个 Frame 和 N 个 World 时，我们有 M * N 个 Context（但 Context 是延迟创建的）。

在 worker 的情况下，只有一个 World 和一个全局对象。因此只有一个 Context。

再次强调，当你使用 V8 API 时，你应该非常小心使用正确的上下文。否则，最终会导致 JavaScript 对象在隔离的 World 之间泄漏，并导致安全灾难（例如，来自 A.com 的扩展程序可以操纵来自 B.com 的扩展程序）。

如果你想了解更多信息：

bindings/core/v8/V8BindingDesign.md

V8 API

在 //v8/include/v8.h 中定义了许多 V8 API。由于 V8 API 是低级的并且难以正确使用，因此 platform/bindings/ 提供了许多包装 V8 API 的辅助类。你应该尽可能多地使用这些辅助类。如果你的代码必须大量使用 V8 API，则文件应放在 bindings/{core,modules} 中。

V8 使用句柄指向 V8 对象。最常见的句柄是 v8::Local<>，它用于从机器堆栈指向 V8 对象。v8::Local<> 必须在机器堆栈上分配 v8::HandleScope 后使用。v8::Local<> 不应在机器堆栈外使用：

c++

void function() {
  v8::HandleScope scope;
  v8::Local<v8::Object> object = ...;  // 这是正确的
}

class SomeObject : public GarbageCollected<SomeObject> {
  v8::Local<v8::Object> object_;  // 这是错误的
};

如果要从机器堆栈外指向 V8 对象，则需要使用包装器跟踪。但是，你必须非常小心，不要用它创建引用循环。通常，V8 API 很难使用。如果你不确定自己在做什么，请咨询 blink-review-bindings@。

如果你想了解更多信息：

如何使用 V8 API 和辅助类：platform/bindings/HowToUseV8FromBlink.md

V8 包装器

每个 C++ DOM 对象（例如，Node）都有其对应的 V8 包装器。准确地说，每个 C++ DOM 对象每个 World 都有其对应的 V8 包装器。

V8 包装器对其对应的 C++ DOM 对象具有强引用。但是，C++ DOM 对象对其 V8 包装器只有弱引用。因此，如果你想将 V8 包装器保持活动状态一段时间，则必须明确地执行此操作。否则，V8 包装器将被过早收集，并且 V8 包装器上的 JS 属性将丢失...

javascript

div = document.getElementById("div");
child = div.firstChild;
child.foo = "bar";
child = null;
gc(); // 如果我们什么都不做，|firstChild| 的 V8 包装器将被 GC 收集
assert(div.firstChild.foo === "bar"); //...这将失败

如果我们什么都不做，child 将被 GC 收集，因此 child.foo 将丢失。为了使 div.firstChild 的 V8 包装器保持活动状态，我们必须添加一种机制，“只要 div 所属的 DOM 树可以从 V8 访问，就使 div.firstChild 的 V8 包装器保持活动状态”。

有两种方法可以使 V8 包装器保持活动状态：ActiveScriptWrappable 和包装器跟踪.

如果你想了解更多信息：

如何管理 V8 包装器的生命周期：bindings/core/v8/V8Wrapper.md
如何使用包装器跟踪：platform/bindings/TraceWrapperReference.md

渲染流水线

从 HTML 文件交付给 Blink 到像素显示在屏幕上，这是一个漫长的旅程。渲染流水线的架构如下。

阅读这篇精彩的幻灯片以了解渲染流水线的每个阶段都做了什么。（我认为我无法写出比这更好的解释了 :-)）

如果你想了解更多信息：

有问题吗？

你可以将任何问题提交至 blink-dev@chromium.org（一般问题）或 platform-architecture-dev@chromium.org（与架构相关的问题）。我们随时乐意提供帮助！:D

←Back to home

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

YieldRay

Blink 工作原理

Preview: