Chromium 多线程机制分析

1.  Chromium采用了多线程机制.在浏览器中采用多线程是一个趋势,IE8和firefox等浏览器也采用了多线程机制.

  Chromium中线程有几类:

1)    Browser process

2)    Render process 可有多个

3)    Plugin process,关于这个,我不是很清楚,一个插件是一个process,还是所有插件在一个process上

4） gpu process

2. 多线程对于浏览器有很多优点:

1)    各个tab页面更大程度上保持独立,减小相互之间的影响.一个tab挂掉,只是一个render process死掉,不会导致其他tab,乃至整个浏览器的挂掉

        2)    浏览器各个模块更大程度地实现宽耦合

3)    减小UI主线程的任务,保持UI较高的反应速度.

 3. 在chromium中,支持几种不同的多进程策略:

   1) Process-per-site-instance:用户打开一个站点网页，从此网站打开的一系列连接属于一个进程;

   2) Process-per-site:一个站点一个进程

   3) Process-per-tab:一个tab页面一个进程；

   4) Single process 单进程模式

   关于这块知识，可以参考官网文档：

  http://www.chromium.org/developers/design-documents/process-models。Chrome浏览器默认采用第一种模型，也可以用命令行切换模式。

  下面，我们针对模式Process-per-tab进行讲解下。

  4. 在该种模式下，browser process作为主进程，管理整个主框架的逻辑，负责UI显示和窗口管理；每个tab是一个进程（render process）,渲染进程即沙箱进程。Browser process 管理所有render process，render process的创建由Browser process完成，并且生命周期要短于browser process。当browser process崩溃死掉的时候，各render process也会死掉。

   5. 下面说说browser process和render process之间的结构组成与两个线程之间的交互方式。

上图来自chromium官网：

http://www.chromium.org/developers/design-documents/multi-process-architecture

通过上图可以看出：

Browser process由main thread和I/O thread组成；

每个Render process由main thread 和render thread。

Browser process中main thread负责管理render process的显示。

针对每个render process会创建一个RenderProcessHost对象来管理该render process。而每个render processs可以维护多个RenderView。针对每个RenderView，在Browser process的main thread中有RenderViewHost对应。每个render process有一个ID，而每个render process中的renderView也有一个view ID，所以，找到一个View，需要先找到管理该View的render process。

  RenderViewHost对象由RenderProcessHost对象维护；RenderView对象由RenderProcess对象维护。

  Browser process中I/O thread负责与render process的main thread进行通讯，通讯机制为IPC，下个blog我们再具体讲讲IPC通讯机制。

 Render process中的render thread负责该进程中所有renderView和webkit代码运行。