Chromium 的多进程架构

October 26, 2024

翻译自：https://www.chromium.org/developers/design-documents/multi-process-architecture/

Chromium 的多进程架构

本文档描述了 Chromium 的高层架构以及它如何在多种进程类型之间划分。

问题

构建一个永不崩溃或永不卡死的渲染引擎几乎是不可能的。构建一个绝对安全的渲染引擎也几乎是不可能的。

在某些方面，2006 年左右的网络浏览器状态类似于过去的单用户协作式多任务操作系统。正如在这样的操作系统中，一个行为不当的应用程序可能会导致整个系统崩溃，一个行为不当的网页也可能会导致网络浏览器崩溃。只需要一个渲染引擎或插件错误就可以导致整个浏览器及其所有当前运行的标签页崩溃。

现代操作系统更加健壮，因为它们将应用程序放入彼此隔离的独立进程中。一个应用程序的崩溃通常不会损害其他应用程序或操作系统的完整性，并且每个用户对其他用户数据的访问受到限制。Chromium 的架构旨在实现这种更健壮的设计。

架构概述

Chromium 使用多个进程来保护整个应用程序免受渲染引擎或其他组件中的错误和故障的影响。它还限制了每个渲染引擎进程对其他进程和系统其余部分的访问。在某些方面，这为网络浏览带来了内存保护和访问控制为操作系统带来的好处。

我们将运行 UI 并管理渲染器和其他进程的主进程称为“浏览器进程”或“浏览器”。同样，处理网页内容的进程称为“渲染器进程”或“渲染器”。渲染器使用 Blink 开源布局引擎来解释和布局 HTML。

管理渲染器进程

每个渲染器进程都有一个全局 RenderProcess 对象，用于管理与父浏览器进程的通信并维护全局状态。浏览器为每个渲染器进程维护一个对应的 RenderProcessHost，用于管理渲染器的浏览器状态和通信。浏览器和渲染器使用 Mojo 或 Chromium 的传统 IPC 系统进行通信。

管理框架和文档

每个渲染器进程都有一个或多个 RenderFrame 对象，它们对应于包含内容的文档的框架。浏览器进程中相应的 RenderFrameHost 管理与该文档关联的状态。每个 RenderFrame 都被赋予一个路由 ID，用于区分同一渲染器中的多个文档或框架。这些 ID 在一个渲染器内部是唯一的，但在浏览器中不是唯一的，因此识别一个框架需要 RenderProcessHost 和路由 ID。浏览器与渲染器中特定文档之间的通信是通过这些 RenderFrameHost 对象完成的，这些对象知道如何通过 Mojo 或传统 IPC 发送消息。

组件和接口

在渲染器进程中：

RenderProcess 处理与浏览器中相应 RenderProcessHost 的 Mojo 设置和传统 IPC。每个渲染器进程只有一个 RenderProcess 对象。
RenderFrame 对象与其在浏览器进程中相应的 RenderFrameHost（通过 Mojo）和 Blink 层进行通信。此对象表示标签页或子框架中一个网页文档的内容。

在浏览器进程中：

Browser 对象表示一个顶级浏览器窗口。
RenderProcessHost 对象表示单个浏览器 ↔ 渲染器 IPC 连接的浏览器端。浏览器进程中每个渲染器进程都有一个 RenderProcessHost。
RenderFrameHost 对象封装了与 RenderFrame 的通信，而 RenderWidgetHost 处理浏览器中 RenderWidget 的输入和绘制。

有关此嵌入工作原理的更多详细信息，请参阅Chromium 如何显示网页设计文档。

共享渲染器进程

通常，每个新窗口或标签页都会在一个新进程中打开。浏览器将生成一个新进程并指示它创建一个 RenderFrame，该 RenderFrame 可能会在页面中创建更多 iframe（可能在不同的进程中）。

有时，在标签页或窗口之间共享渲染器进程是必要或可取的。例如，Web 应用程序可以使用 window.open 创建另一个窗口，如果新文档属于同一来源，则它必须共享同一进程。如果进程总数过大，Chromium 也有策略将新标签页分配给现有进程。这些考虑因素和策略在进程模型中进行了描述。

检测崩溃或行为不当的渲染器

与浏览器进程的每个 Mojo 或 IPC 连接都会监视进程句柄。如果这些句柄发出信号，则渲染器进程已崩溃，受影响的标签页和框架将收到崩溃通知。Chromium 会显示一个“悲伤标签页”或“悲伤框架”图像，通知用户渲染器已崩溃。可以通过按下重新加载按钮或启动新的导航来重新加载页面。发生这种情况时，Chromium 会注意到没有渲染器进程，并创建一个新的渲染器进程。

沙盒化渲染器

鉴于渲染器在单独的进程中运行，我们有机会通过沙盒化限制其对系统资源的访问。例如，我们可以确保渲染器只能通过 Chromium 的网络服务访问网络。同样，我们可以使用主机操作系统的内置权限限制其对文件系统的访问，或限制其对用户显示和输入的访问。这些限制极大地限制了受损渲染器进程所能完成的操作。

释放内存

由于渲染器在单独的进程中运行，因此将隐藏的标签页视为低优先级变得很简单。通常，Windows 上最小化的进程会将其内存自动放入“可用内存”池中。在内存不足的情况下，Windows 会将此内存交换到磁盘，然后再交换出更高优先级的内存，从而帮助保持用户可见程序的响应速度。我们可以将相同的原则应用于隐藏的标签页。当渲染器进程没有顶级标签页时，我们可以释放该进程的“工作集”大小，作为提示系统在必要时首先将该内存交换到磁盘的提示。因为我们发现减少工作集大小也会降低用户在两个标签页之间切换时的标签页切换性能，所以我们逐渐释放此内存。这意味着，如果用户切换回最近使用的标签页，则该标签页的内存比最近未使用过的标签页更有可能被分页。拥有足够内存来运行所有程序的用户根本不会注意到此过程：Windows 只会在需要时实际回收此类数据，因此在内存充足时不会出现性能损失。

这有助于我们在内存不足的情况下获得更佳的内存占用。与很少使用的后台标签页关联的内存可以完全交换出去，而前台标签页的数据可以完全加载到内存中。相比之下，单进程浏览器会将其所有标签页的数据随机分布在其内存中，并且无法如此清晰地分离已使用和未使用的的数据，从而浪费内存和性能。