Chrome的进程体系

概述

  Chrome最核心的部件主要有三个：Browser、Renderer、Webkit。Browser是老大，控制了所有的I/O、网络传输、浏览器主界面等工作，Renderer顾名思义，主要负责渲染工作，并由Browser进程驱动，Chrome支持每一个Renderer为一个独立进程模式，也就是在Chrome中看到的每一个Tab页面都可以是一个独立进程，某一个Tab页面Crash，不影响其他页面的运行。Renderer进程的实际渲染工作由Webkit库来完成。

Chrome的多进程架构

下图就是Google官网上公布的Chrome多进程示意图。



Chrome的进程模型（参考网上文档，作者(duguguiyu)：

Google在宣传的时候一直都说，Chrome是one tab one process的模式，其实，这只是为了宣传起来方便如是说而已，基本等同广告，实际疗效，还要从代码中来看。实际上，Chrome支持的进程模型远比宣传丰富，你可以参考一下这里 ，简单的说，Chrome支持以下几种进程模型：

1.   Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。
2.   Process-per-site： 同域名范畴的网站放在一个进程，比如www.google.com和www.google.com/bookmarks就属于一个域名内（google有自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行--process-per-site开启。
3.   Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系，就和宣传的那样。用--process-per-tab开启。
4. Single Process：这个很熟悉了吧，传统浏览器的模式，没有多进程只有多线程，用--single-process开启。

 

Chrome包含了一个Browser进程和多个Renderer进程。当然还包含了上图中未反馈出来插件进程，在Chrome中每一个插件也是一个独立的进程。

 

每一个Renderer进程中都包含了一个RenderProcess对象，其主要工作是负责Renderer进程和Browser的通讯。对应的在Browser进程中为每一个Renderer进程提供了一个RenderProcessHost对象（Renderer进程中包含了不同类型的RenderProcessHost对象）。这个对象负责与各个Renderer进程通讯。Browser进程和Renderer进程之间的通讯采用IPC方式（Inter-process
Communication）。后续我们将详细讲解这部分。

如上面所述，Chrome的进程模型中Process-per-site-instance和Process-per-site两种模式下，多个Tab页面同属于一个进程。为了适应这种情况，Chrome提供了另外的解决方案。在每一个Renderer进程中，包含了一个或者多个RenderView对象，这个对象被RenderProcess对象管理。每一个Tab页面就是一个RenderView。但在Process-per-site-instance和Process-per-site两种模式下，有可能多个Tab页面都同属于一个Renderer进程。被同一个RenderProcess对象管理。为了区分每一个RenderView，Renderer进程为每一个RenderView分配了一个viewID，这个ID在同一个Renderer进程内是唯一的。但不保证全局唯一。每一个RenderView与Browser进程通讯时，必须提供RenderProcess对象和ViewID两个信息，才能指示当前的RenderView。对应的在Browser进程中也包含了一个RenderViewHost对象，负责与Renderer进程中的RenderView对象通讯。

打开Chrome后，选择Shift + Esc可以查看Chrome的进程和内存情况。（下图中采用的是Chrome的缺省模式）。



 

从上图中我们可以看出，我们一共打开了4个Tab页面，统计结果显示，总共包含了5个进程。

 

1. Browser进程，进程ID为4500。

 

2. Google Tab页面，这是单独打开的一个Tab页面。拥有一个独立的进程。进程ID为5128。

 

3. AboutMemory Tab页面进程，就是按下Shift+Esc后的页面子进程。进程ID为1218。

 

4. CSDN Tab页面进程，我通过CSDN主页面又点击了一个新的页面（上图Chrome采用的是缺省模式），可以看到这两个Tab页面同属于一个进程，进程ID为3732。

 

5.Flash播放进程，由于CSDN网页上有Flash,因此Browser进程启动了Flash显示插件进程。进程ID为10944。

 

对应在任务管理器中，我们可以看到相应的5个进程：
 

Chrome的进程模型分析

目前市面上的其他浏览器如IE、Firefox、Safari均是单进程模式，Chrome则支持上节所描述的四种进程模型。从Chrome官网的描述来看，Google打造Chrome的目的并不是做一个简单的浏览器，Google的愿景是要把Chrome打造成一个虚拟的操作系统平台，为了这个操作系统平台的健壮性和安全性，Google采用了独立的多进程模式来隔离多个Renderer以及Browser本身。每一个进程都运行在自己的进程空间中，被操作系统统一调度，因此可靠性和安全性得到大大提升。（小小八卦一下，目前网上有一款世界之窗浏览器，世界之窗3.0版本已经支持了类似于Chrome的进程模式，参考网上的评论，算是一个山寨版的Chrome浏览器，连风格都和Chrome很相似了。不过世界之窗采用的是IE内核，非WebKit内核。）

 

PS：现在世界之窗6.0已经采用了chrome内核，但是没有chrome开发者工具，还有一些采用IE内核的浏览器的常用功能并没有完善，希望能进一步得到完善。