Chromium多进程模型

概述

相信你一定有这样的经历：打开很多个页面，不幸的是其中某个页面不响应了或者崩溃了，随之而来的是更不幸的事，所有页面都不响应或者都崩溃了。最让人崩溃的是其中一些页面还有未保存或者未发送的信息！

这绝对是不堪回首的过去。但是，现在好了，现代浏览器很多都支持多进程模型，这个模型可以很好地避免上面的问题，虽然它很复杂而且也有自身的问题，例如更多的资源消耗，但是它的优势也是非常明显地。

chromium的多进程架构至少带来三点好处，其一是避免单个页面的不响应或者奔溃影响整个浏览器的稳定性；其二是当第三方插件奔溃时候不会影响页面或者浏览器的稳定性；其三是方便了安全模型的实施，也就是说沙箱模型是基于多进程架构的。其实，这很大程度上也是WebKit2产生的原因。那么，这是怎么做到的呢?

下图给出了缺省的chromium浏览器的进程模型。方框代表进程，连接线代表IPC进程间通信。 

 

通常来讲，chromium浏览器包括以下主要进程类型：

1. Browser进程：浏览器的主进程，负责浏览器界面的显示，各个页面的管理，其他各种进程的管理；
2. Render进程：页面的渲染进程，负责页面的渲染工作，WebKit的工作主要在这个进程中完成；
3. NPAPI插件进程：每种类型的插件只会有一个进程，每个插件进程可以被多个Render进程共享；
4. GPU进程：最多只有一个，当且仅当GPU硬件加速打开的时候才会被创建，主要用于对3D加速调用的实现；
5. Pepper插件进程：同NPAPI插件进程，不同的是为Pepper插件而创建的进程

Chromium浏览器的进程模型，包括以下特征：

1. browser进程和页面是分开的，这保证了页面的奔溃不会导致浏览器主界面的奔溃；
2. 每个页面是独立的进程，这保证了页面之间相互不影响；
3. 插件进程也是独立的，插件的问题不会影响浏览器主界面和页面；
4. GPU硬件加速进程也是独立的。 因为这么多的进程，开发者通常需要知道进程列表中的进程类别，这很简单，可以通过进程的命令行参数"--type"来识别。 有趣的是，就在我写下上面这段文字的时候，我的chrome浏览器的flash插件崩溃了，幸运的是其他一切都很好，感谢chrome的多进程模型！

模型的类型

其实介绍了进程模型，其实Chromium支持多种进程模型，特别是对页面而言，下面简单的介绍以下模型的类型：

Process-per-site-instance

该类型的含义是对同一个域的实例都会创建独立的进程。举个例子来讲，例如，用户访问了biandroid的CSDN博客（我的博客），然后从个人主页打开多篇文章时，每篇文章的页面都是该域的一个实例，因而它们都共享同一个的进程。如果新打开CSDN博客的主页，那么就是另一个实例，会重新创建进程来渲染它。这带来的好处是每个页面互不影响，坏处自然是资源的巨大浪费。

Process-per-site

该类型的含义是不同一个域会创建独立的进程，同一域的不同实例共享同一个进程。好处是对于不同的域可以共享，相对较小的内存消耗，坏处是可能会有特别大的Renderer进程。可以在命令行加入参数--process-per-site来尝试它。

Process-per-tab

该类型的含义是为每个标签页创建一个独立的进程，这也是chrome/chromium的缺省行为

Single process

该类型的含义是不为页面创建任何独立的进程，所有渲染工作都在browser进程中。但是这个类型只是实验性质的，不稳定，因而不推荐使用，只有在比较单进程和多进程时候比较有用，可以在命令行加入参数--single-process来尝试它。

沙箱模型

在页面的多进程模型中，页面的渲染是运行在沙箱模型中的Render进程中实现的，这些渲染引擎没有访问本地资源的能力（例如文件系统，窗口系统，等等），这可以保护渲染引擎被入侵。

参考文献

1. http://www.chromium.org/developers/design-documents/process-models