Chromium进程模型

原文地址：https://www.chromium.org/developers/design-documents/process-models

这篇文章描述了Chromium所支持的不同进程模型，以及各种模型的优缺点。

1、概述

现在的网页大都包含很多的动态代码，这让它们看起来更像是应用程序，而不是单纯的文档。这种变化使得浏览器也不再是单纯的文档渲染器，而成为了一个“操作系统”。Chromium像一个操作系统一样确保加载的应用程序安全而健壮的运行，使用多个OS进程将网站之间以及网站同浏览器之间隔离开来。每个进程在自己的地址空间内运行，操作系统负责调度，一个进程的崩溃不会影响其他的进程。用户也可以在Chromium的任务管理器中看到每个进程的资源占用情况。

浏览器可以通过多种方法切割成不同的OS进程，架构的好坏包含很多因素，例如稳定性、资源使用、以及对实际使用内存的观测。Chromium 支持四种可供研究的进程模型，以及一个适用于大多数用户的默认模型。

2、支持模型

Chromium支持四种将web页面分配到render进程的模型。默认情况下，Chromium 为用户访问的每个web site实例分配一个独立的OS进程。但是，用户可以使用使用命令行切换进程模型：一个web site的所有实例对应一个进程，一组相关的tab页使用一个进程、整体使用一个进程。不同的模型要么对内容来源的解析不同，要么tab页间的关系不同，或者两者皆有。接下来将更细致的讨论每种模型，以及需要注意的事项。

2.1 Process-per-site-instance

默认情况下，Chromium 为用户访问site的每个实例创建一个renderer进程，这保证了不同site的页面独立渲染，同一个site的不同访问也被隔离起来。因此，一个site访问实例的崩溃或者高资源占用不会影响浏览器其余部分。这个模型基于原始内容的解析以及tab页间的脚本关联关系。所以，两个tab页显示页面可能在同一个进程中渲染，但在一个tab页里导航到一个跨site页面时，可能会造成render进程切换。

具体来说，“site”= 注册域名(e.g. google.com or bbc.co.uk) + 协议（e.g. https://）。

这类似于Same Origin Policy的定义，但它将子域名（例如mail.google.com docs.google.com）和端口（例如 http://foo.com:8080）放在同一个site里，这对同一site不同子域名或者端口的页面通过Javascript访问彼此是必要的。

一个site实例是site里一组页面的组合。两个pages在脚本代码里相互引用，表示它们相互关联（例如：一个page使用Javascript在新窗口中打开另一个page）。

优势

• 将不同site的隔离开来，一个site的crash不会影响其它。
• 将显示相同site内容的不同tab页隔离开来，在不同的tab页中访问相同site会创建不同的进程。一个实例的crash不会影响另一个。

弱点

• 内存消耗变大，比Process-per-site模型创建更多的renderer进程。虽然增加了稳定性，为并行创造了机会，但会有更多的内存消耗。
• 更难实现，比起process-per-tab 和single-process， 此模型需要复杂的逻辑来支持tab页中的进程切换。

2.2 Process-per-site

Chromium 还支持一种隔离不同site访问的进程模型，将同一site的所有实例放到一个进程里。启动Chromium的时候使用--process-per-site 命令行切换。Process-per-site renderer数量变少，在内存占用减少的同时也降低了系统的健壮性。

优势

• 将不同site的隔离开来，如同 process-per-site-instance模型一样，来自不同site的任务对彼此没有影响。
• 更少的内存占用。比process-per-site-instance 和 process-per-tab模型创建的进程少。有效减少了Chromium使用的内存。

弱点

• 增大了renderer进程。像google.com这样的site可能在browser里同时开了很多应用，这些应用在同一个进程中运行。因此，资源竞争和应用崩溃会影响很多的tab页，让浏览器看起来反应迟钝。在不打破向后兼容性的情况下，很难以注册域名更小的限定定义site边界。
• 难以实现，如同process-per-site-instance模型，在导航和代理一些 JavaScript 交互时，它需要支持进程切换。

2.3 Process-per-tab

process-per-site-instance 和process-per-site模型在创建renderer 进程时都考虑内容的来源。Chromium还支持一种更简单的模型，它为每组script-connected的tab页创建一个renderer进程。使用命令行--process-per-tab进行切换。

具体的，我们将一组脚本相关的tab页称为一个browsing instance。这和HTML领域里"unit of related browsing contexts"相呼应。每组包含一个tab页和这个tab页使用Javascript 代码打开的其它tab页。这些tab页必须在同一个进程中渲染，用以支持tab页间的javascript调用。

优势

• 容易理解，每个tab页都有一个为之服务的进程，不随时间改变。

弱点

• 一个页面crash，可能造成其它页面crash。如果用户在browsing instance中的tab页导航到其它site，新的页面会和之前browsing instance中的页面命运共享。

• 值得注意的是，出于安全考虑，Chromium process-per-tab 模型在某些情况下，也会强制tab页进行进程切换。例如，普通页面不允许和Settings、新空白标签页等特殊页面命运共享。因此，这个模型实际上也没有比process-per-site-instance简单多少。

2.4 Single Process

最后，出于对比的目地，Chromium也支持一个单进程模型，使用--single-process进行切换。在这个模型中，browser和 render全都在同一个OS进程中运行。

单进程模型为测量其它多进程模型提供了对比样本。它不是一个安全和健壮的架构，因为任何一个render的崩溃都会造成整个browser崩溃。设计它仅用于测验和学习目的，而且它可能包含其它模型所没有的bug。

3、沙盒和插件

每个多进程结构中，Chromium所有的render进程都在一个只能访问用户电脑有限资源的沙盒进程中执行。这些进程不能直接访问用户的文件系统、显卡和其它大部分资源。它们通过browser进程获得可以访问资源的许可，browser为这些访问添加安全条件。因此，比起可以直接访问的render引擎，Chromium的browser进程能减轻应用对用户造成的潜在危害。

Browser插件，例如Flash 和 Silverlight，都在它们自己的进程里执行，一些像Flash的这样的插件，甚至在Chromium的沙盒中运行。

在Chromium 所支持的多进程架构中，每种类型的动态插件有且仅有一个进程实例。因此，不管来自那个site，在哪个tab页中使用，所有的Flash实例在同一个进程中运行。