Chromium学习笔记（一）——Chromium框架及进程模型

0. 引言

       Chrome作为如今最受欢迎的浏览器之一，其开源内核Chromium从诞生之日起就得到了广泛关注，目前市面上很多浏览器都是基于Chromium内核的，其性能很大程度上基于Chromium的优秀品质。那么，Chromium究竟是一个怎样的框架呢？它又有哪些优秀特性呢？作为一个浏览器新手，我希望能通过自己一段时间的学习，对这些问题有一个初步的理解，同时将自己的学习心得分享给大家。

1. Chromium框架总览

       首先，Chromium是一个多进程框架。不少人一看到多进程，就会觉得效率低，因为进程的创建和销毁、进程间的通信，远比单进程中的多线程消耗更多。可事实并不是想象的那么简单，衡量一个应用程序的好坏，往往在于用户的真实体验，Chromium内核这么受欢迎，说明多进程自然有多进程的好，同时也说明Chromium的多进程框架的确有其独到之处（当然，大牛们说Chromium更为出彩的地方还是在多线程的并发管理，下一篇就会研究这里）。闲话不多说，先把这张经典的图放上来。

       在上面这幅图中我们可以看到两类进程：第一类，Browser进程，它管理tabs和插件进程以及运行主界面UI；第二类，Renderer进程，它利用WebKit布局引擎来解释和布局HTML。其实还有另一类进程，Plugin，顾名思义，其与浏览器插件对应。Browser是Chromium的主进程，是老大，只有一个；Render进程和Plugin进程都与老大保持进程间的通信，某些Render进程与Plugin进程之间也有彼此联系的通路，而是多个Render进程之间或者多个Plugin进程之间，是没有直接通信的途径的，全靠老大协调。老大与其他各进程之间的通信，是用IPC（Inter-Process Communication）实现的，这是google自己搭的一套进程间通信机制，在之后专门研究Chromium进程间通信的文章里会介绍。

       更细一步，Browser和Renderer进程里还包含多个线程（Plugin进程之后再讲）。Renderer通常有两个线程，Main thread负责与主进程之间的通信，而Render thread则是负责Renderer本身的任务——网页的渲染和交互。相比之下，主进程Browser拥有更多的线程，除了大脑般负责管理的Main thread，和负责与Renderer进程通信的IO thread，其实还包括负责管理文件的file thread，负责管理数据库的db thread等等。在图中我们可以看到，主进程的Main thread中包含多个RenderProcessHost，每一个RenderProcessHost都对应着一个RenderProcess（当然PluginProcessHost也会对应PluginProcess），也就是说，有多少个**ProcessHost实例，就有多少个除主进程之外的进程在运行。

2. Chromium的几种进程模型

       Chromium事实上一共有4种进程模式：

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开启。

       感兴趣的话，可以在不同模式下用Shift+Esc打开Chrome自己的任务管理器查看各进程的状况。

3. Renderer进程浅析

       暂时不研究Plugin，只谈Renderer。回头再看一眼Chromium框架图，在Renderer进程的Render thread中，都出现了RenderView，在Chromium中，用RenderView表示一个web页面，一个RenderView可以寄宿在任一一个RenderProcess中，它只是依托 RenderProcess帮助它进行通信。每一个RenderProcess进程都可以有1到N个。

       如上一节所说，Chromium支持4种不同的进程模型。但实际上管理RenderView的基本模式是一致的，当需要创建一个新的RenderView的时候，Chromium会尝试进行选择或者是创建进程。 比如，在one site one process的模式下，如果存在此site，就会选择一个已有的RenderProcessHost，让它管理这个新的RenderView，否则，会创建一个RenderProcessHost（同时也就创建了一个Renderer进程），把RenderView交给它对应的RenderProcess中的RenderView实例（这句话略绕╮(╯▽╰)╭）。不过，Renderer进程的总数是有上限的，由机器内存大小决定，例如对2G内存，这个上限数为20，当Renderer进程数达到上限后，再打开新的网站，Chromium会随机选择一个已有的Renderer进程，把新创建的RenderView放进去。

       另外，值得一提的是，Chrome并没有进程池之类的特殊机制，而是简单的履行有就创建、没有就销毁的策略。比如，打开新建标签页之后，输入一串url，打开了一个网站（如www.google.com），原来新建标签页对应的进程就会被销毁，同时创建一个google网页的进程，当再次输入url进入一个新网站，如blog.csdn.net/zuolittletian时，google网页的进程就会销毁，再次建立新打开网页的进程。

4. 小实验

       纸上得来终觉浅，绝知此事要躬行。”我们来做个小实验理解一下Chromium的各种进程模型吧。

       在Chrome的快捷方式上，右键，“属性”，“快捷方式”标签的“目标”中，加空格，再加入上面提到的几种命令，如“--process-per-site”，重新打开浏览器，即可进入不同模式。

Process-per-site-instance模式（默认模式）下的进程状态：

其中两个CSDN的网站，第二个是在第一个页面的链接打开的。

Process-per-site模式下的进程状态：

两个百度网页是在不同tab下进入的，却属于同一个进程。

Process-per-tab模式下的进程状态：

Single Process模式……这个有点囧，试了几次总是失败，查了一下原来已经被禁用了。

不过以上几个实验还是验证了Chromiumqian前三种进程模式的运行方式，实验基本成功^_^