Chromium多进程架构

原文地址：http://www.chromium.org/developers/design-documents/multi-process-architecture

1、多进程架构

浏览器引擎不可能绝对稳定，也不可能绝对安全。

某种程度上，当前的Web浏览器类似于之前单用户、多任务协同工作的操作系统。

现代操作系统使用不同的进程将不同的应用隔离起来，因而更加健壮。一个应用程序的的崩溃一般不会影响其他应用程序，也不会影响操作系统的完整，而且用户对其他用户数据的访问受到限制。

2、结构概述

为了减少浏览器内核的bug，我们将不同的Tab页用不同的进程隔离起来。进程间的访问受限，对系统其他部分的访问也受限。这使得web浏览器获得了类似内存保护和访问控制给操作系统带来的好处。

我们将UI和管理Tab页、插件进程的主进程称为browser进程或者browser。同样的，一个特定tab页对应的进程被称为render进程或者renderers。这些renderers使用WebKit开源布局引擎来解释和布局HTML。

4、管理视图

每个Render进程有一个或多个RenderView对象，通过Render里的全局对象 RenderProcess管理，对应着tab页里的内容。

Browser里的RenderProcessHost 为每一个View维护一个RenderViewHost。用ID号来标识同一个Render里不同的View。ID值在一个Render里是不同的，但不保证在Browser里不同，所以要需要一个RenderProcessHost和一个ViewID才能定位到一个View。Browser和特定tab页里的特定view通过这些RenderProcessHost对象来通信，它们知道怎样从RenderProcessHost发送消息到 RenderProcess并最终作用于RenderView。

5、组件和接口

在render进程里

• RenderProcess（Render端）维持着与RenderProcessHost（Browser端）间IPC通信。每个render进程只有一个RenderProcess对象，这就是browser和所有的renderers间通信的方式。
• Renderview（Render端）通过RenderProcess（Render端）以及WebKit嵌入层和RenderViewHost （Browser端）通信。Renderview对象代表一个tab页的内容或者一个弹出窗口。

在browser进程里

• Browser对象代表一个最高级别的的浏览器窗口。
• RenderProcessHost（Browser端）对象代表一个 Browser和Renderer间的IPC连接。每个render进程对应browser进程里的一个RenderProcessHost。

• RenderViewHost（Browser端）对象将同远端Renderview（Render端）的通信封装进内部，RenderWidgetHost（Browser端）对象控制着RenderWidget（Render端）的输入和绘制。

可以在How Chromium displays web pages 设计文档里查看更详细的内容。

6、共享render进程

一般来说，每个新的窗口或者tab页在一个新的进程里创建。Browser会产生一个新的进程并指导它创建一个 RenderView（Render端）。

有时，在tab页或者窗口间需要共享render进程。一个web应用创建了一个新的窗口，想和它同步通信，例如使用JavaScript的window.open。这种情况下，当我们创建一个新的窗口或者tab页，需要重用这个窗口的进程。当总线程个数太大的或者已经有导航到那个域名的进程的时候，我们需要一种策略将新的tab页绑定到已经存在的进程里。这些策略在Process Models有详细描述。

7、探测未正常运行的Renderers

每个同browser进程的IPC连接都会监听进程句柄。句柄指示异常表示render进程崩溃，tab页能感知到这种异常。目前，我们用一个崩溃页面告诉用户这个进程已经崩溃。可以通过点击重新加载按钮或者开启新的导航来重新加载页面。这样的操作发生时我们会发现没有对应的进程并创建一个新的。

8、将renderer放入沙盒

考虑到Webkit在单独的进程里运行，我们有机会限定它对系统资源的访问。例如，我们能保证renderer对网络的访问是通过父browser进程完成的。同样的，我们也可以使用操作系统内置的许可限制render对文件系统的访问。

除了限制renderer对文件系统和网络的访问，我们也可以给它对用户显示和相关对象的访问加上权限。每个线程可以在其他线程不可见的系统桌面上运行。这阻止了被盗用的renderer开启窗口或者捕获按键。

9、内存回收

Renderers在不同的线程中运行，自然而然将隐藏的tab页置为低优先级。通常，Windows操作系统将进程内存放入“可用内存”池来减少内存占用。在内存吃紧的情况下，WIndows会将低优先级的内存置换到硬盘，确保用户可见的程序交互更顺畅。我们可以将这种规则应用到隐藏的tab页中。如果必要，当一个render进程没有高级别tab页的时候，可以暗示操作系统将render的工作集内存置换到硬盘里。我们逐渐的释放这些内存，因为工作集内存的释放帮随着切换tab页性能变差的后遗症。这意味着，用户切回刚用过的标签页比切回很久没有使用的标签页工作集内存准备好的几率更高。如果用户有足够的内存跑起来所有的程序，将不会进行内存置换。

Windows只在必要的时候这么做，所以内存足够的时候将不会有性能忧虑。

这帮助我们在低内存环境有一个更优化的内存占用模式。几乎不用的低级别标签页内存可以置换出去，而高级别标签页的数据可以完全加载到内存中。相比之下，单进程浏览器将所有选项卡的数据随机分配到内存，几乎没有可能完全分离未用和已用的数据，既浪费内存又浪费性能。

10、插件

火狐风格的NPAPI插件在它们自己的进程中运行，和renderer隔离了开来，这在 Plugin Architecture里有详细的介绍。