现在的位置: 首页 > 综合 > 正文

Chrome的进程体系

2018年03月19日 ⁄ 综合 ⁄ 共 2464字 ⁄ 字号 评论关闭

概述

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

Chrome多Tab窗口

Chrome的多进程架构

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

Chrome多进程结构

Chrome的进程模型(参考网上文档,作者(duguguiyu):

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

1.    Process-per-site-instance:就是你打开一个网站,然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式

2.    Process-per-site同域名范畴的网站放在一个进程比如www.google.comwww.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-instanceProcess-per-site两种模式下,多个Tab页面同属于一个进程。为了适应这种情况,Chrome提供了另外的解决方案。在每一个Renderer进程中,包含了一个或者多个RenderView对象,这个对象被RenderProcess对象管理。每一个Tab页面就是一个RenderView。但在Process-per-site-instanceProcess-per-site两种模式下,有可能多个Tab页面都同属于一个Renderer进程。被同一个RenderProcess对象管理。为了区分每一个RenderViewRenderer进程为每一个RenderView分配了一个viewID,这个ID在同一个Renderer进程内是唯一的。但不保证全局唯一。每一个RenderViewBrowser进程通讯时,必须提供RenderProcess对象和ViewID两个信息,才能指示当前的RenderView。对应的在Browser进程中也包含了一个RenderViewHost对象,负责与Renderer进程中的RenderView对象通讯。

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

Chrome进程查看

 

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

 

1. Browser进程,进程ID4500

 

2. Google Tab页面,这是单独打开的一个Tab页面。拥有一个独立的进程。进程ID5128

 

3. AboutMemory Tab页面进程,就是按下Shift+Esc后的页面子进程。进程ID1218

 

4. CSDN Tab页面进程,我通过CSDN主页面又点击了一个新的页面(上图Chrome采用的是缺省模式),可以看到这两个Tab页面同属于一个进程,进程ID3732

 

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

 

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

Chrome进程

Chrome的进程模型分析

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

 

抱歉!评论已关闭.