Chrome设计文档-多进程架构

chromium multi-process architecture

本文档从high-level的角度描述Chromium的多进程架构。

问题

要构建一个决不崩溃或挂起的渲染引擎几乎是不可能的。一样的，要构建一个100%安全的渲染引擎也是不可能的。

从某些角度来看，当今的web浏览器有点相似于过去的单用户，多任务操做系统。正如一个异常的程序会致使整个系统down掉，一个异常的网页也会致使一个现代浏览器挂掉。

现代操做系统之因此更加健壮利益于它们把应用放到隔离的进程中。一个应用的崩溃不会影响其它的应用或者操做系统自己。任一用户对其它用户的数据操做都是严格受限的。

架构概述

咱们针对浏览器的tab使用隔离的进程。这种方案能够保护应用自己完整，不受渲染引擎的bugs或小差错的影响。同时，咱们也严格限制从渲染引擎到其它进程的访问。从某些方面来看，这给网页浏览带来了内存保护和访问控制的收益。而这两点均借鉴自操做系统。

咱们把主进程称为“browser process（浏览进程）或browser”。该进程负责UI的运行和tab的管理工做，同时，也负责插件进程的管理工做。相似的，tab特定的进程被称为“render process”或者“renderer”。Renderers使用”WebKit”开源引擎解析并布局HTML文档。

管理渲染进程（Rendering process / Renderer）

每个Renderer对应一个全局的RenderProcess对象。该对象管理Renderer与父进程Browser process间的通讯，并维护全局状态。Browser则维护多个RenderProcessHost对象。每一个RenderProcessHost对应一个Renderer。Browser负责策略浏览状态以及与Renderer的通讯。Browser与Renderers间的通讯由Chromium的IPC系统承担。

管理Views

每一个Renderer有一个或多个RenderView对象。一个Renderer至关于一个tab。相应的，RenderProcessHost维护一个RenderViewHost。一个RenderViewHost对应于Renderer中的一个view。同一个Renderer中，为了区分不一样的view，每一个view会被分配一个ID。这些ID在同一个Renderer里是惟一的，但在browser里并非。因此，要标识一个view，须要RenderProcessHost和一个view ID。

组件和接口

在Render进程里：

• RenderProcess负责处理与RenderProcessHost间的IPC。RenderProcessHost位于Browser中。每个Render进程仅一个RenderProcess。全部的browser和renderer间的通讯都是这样子的。
• RenderView对象与browser进程中的RenderViewHost通讯（固然，是经过RenderProcess完成的）。RenderView表明一个网页上的内容或弹出窗口中的网页内容。

在Browser进程中：

• Browser对象表明一个顶层的browser窗口
• RenderProcessHost表明browser端的browser<->renderer ipc链接。在browser里，每个render进程对应一个RenderProcessHost。
• RenderViewHost封装了与远端的RenderView间的通讯流程。RenderWidgetHost处理输入和RenderWidget的绘制。

共享Renderer

一般，一个新窗口或新tab打开一个新的进程。浏览器会生成一个新进程，而后，指令它去建立一个单独的RenderView。

有时，tabs或windows间共享Renderer也是必须的或者很是有必要的。好比，一个web应用使用window.open打开一个同步模式的新窗口。这种状况下，当咱们建立一个新窗口或tab时，咱们须要复用原进程，即窗口打开者所在的进程。对于进程数过多的状况，咱们也有相应的策略把新tab交给已存在的进程。这些策略参见Process Models。

崩溃探测或渲染异常

每个到browser进程IPC连接会监控渲染进程(renderer)的句柄。若是这些句柄收到信号，那么渲染进程已经崩溃，tab页收到崩溃通知。从今开始，当Renderer崩溃时，咱们会显示一个”sad tab“屏来通知用户。当前页面能够经过点击”preload“按钮从新加载。

Renderer沙盒化

假设WebKit在一个分离的进程中运行，咱们有机会控制它对系统资源的访问。好比，咱们能够限定renderer的网络操做只能经过其父进程完成。相似的，咱们也能够严格限制它对文件系统的访问。

Plug-ins

NPAPI插件运行在本身的进程中，与renderers分离。详情参见Plugin Architecture。