Chromium多进程架构

原文链接:http://dev.chromium.org/developers/design-documents/multi-process-architecture

这篇文章是从高层的架构来描述chromium,每个新接触chromium的人最好都能理解这篇文章的概念。

chromium为浏览器标签页使用隔离开的进程,使得浏览器渲染引擎的错误不会导致整个浏览器的错误。也限制每个渲染引擎进程去访问其他进程和系统。在某些方面,独立的多进程架构可以利用操作系统带来的内存保护和访问控制的好处。

我们运行界面、管理标签页和插件的进程称为主进程,或者是浏览器进程,浏览器。而每个标签页所对应的进程称之为渲染进程或者渲染器。渲染器使用webkit来解释排布html。

arch (1)

管理渲染进程

每个渲染进程有个全局的RenderProcess对象来管理跟他的父进程也就是浏览器进程的通信和维护各种全局状态。浏览器进程则是为每个渲染进程维护对应的RenderProcessHost对象,用来管理浏览器状态和跟渲染进程通信。浏览器进程和渲染进程是通过Chromium’s IPC 系统来通信的。

管理视图

每个渲染进程拥有由RenderProcess管理着的一个或者多个RenderView对象,每个对应着标签页上的内容。对应的RenderProcessHost维护着一个RenderViewHost对应这渲染进程的里面的每个视图。在一个渲染器里面,每个视图通过视图ID来区分比彼此。这个ID在一个渲染器里面是唯一的,对于浏览器则不是。所以为了指明某个视图需要RenderProcessHost和视图ID。浏览器跟某个标签页之间的通信通过RenderViewHost对象,它知道如何通过RenderProcessHost发送消息到RenderProcess和RenderView。

组件和接口

在渲染进程里面:

  • RenderProcess处理IPC跟浏览器里面对应的RenderProcessHost
  • RenderView对象跟在浏览器里面对应的RenderViewHost通信(通过RenderProcess)

在浏览器进程里:

  • Browser对象代表最上层的浏览器窗口
  • RenderProcessHost对象代表browser ↔ renderer IPC 通信的browser端。browser process一个RenderProcessHost对应一个 render process
  • RenderViewHost对象封装了与远程RenderView之间的通信,RenderWidgetHost在browser里处理RenderWidge的输入和绘制

共享渲染进程

一般打开每个新的窗口和标签会创建一个新进程。browser创建一个新进程然后在里面创建单个RenderView。
有时候需要在标签或者窗口直接共享render process。一个web应用打开一个新窗口预计将要同步通信,比如javascript使用window.open。这种情况当我们创建一个新标签或窗口,需要重用打开窗口的进程。有种策略是当总进程数超过限制时需要附加新的标签到现存的进程,或者用户先前有个进程打开了同一个域名。

检测崩溃和错误的渲染

每个连接到browser process的IPC监视一个进程句柄。如果这些句柄是有信号的,表示render process已经崩溃,那么标签上就会给出提示。

沙箱化渲染进程

鉴于webkit运行在隔离的进程中,我们可以限制它访问系统资源。比如,我们能确保renderer只能通过父进程去访问网络。同样,我们可以使用操作系统的内置权限限制它访问文件系统。
除了限制renderer访问文件系统和网络,我们还可以限制它访问用户显示器和其他相关对象。我们在一个用户不可见的隔离的window桌面运行render。这会防止一个恶意renderer打开一个新窗口或者监视用户键盘输入。

回收内存

鉴于renderers运行在隔离的进程中,简单把隐藏的标签进程设置为低优先级。在低优先级下,windows会把交换内存数据到硬盘,再把高优先级进程的数据换回内存。提高用户可见程序的响应。当一个render process不是在顶级标签,如果有需要我们可以释放进程工作集。在两个标签之间切换的时候发现减少用户工作集会减弱标签切换的性能,所以我们是逐渐的释放。

插件

Firefox类的NPAPI插件运行在独立的进程,跟渲染进程隔离开。

发表评论

电子邮件地址不会被公开。 必填项已用*标注