Chromium是什么？
Chromium是谷歌浏览器引擎，是谷歌的一个开源项目。
Chromium多进程框架
有一个主进程，称为Browser，管理Chromium大部分的日常事务；
有很多Renderer，它们圈地而治，各管理一组站点的显示和通信，它们只和Browser通信。它们和Browser通信的渠道，称做IPC（Inter-Process Communication），这是Google搭的一套进程间通信的机制。
Chromium进程模型
在Browser中，有n个xxxProcessHost，每一个host，都对应着一个Process，比如RenderProcessHost对应着RenderProcess，PluginProcessHost对应着PluginProcess，有多少个host的实例，就有多少个进程在运行。Browser对Host的操作，都会被Host封装成IPC消息，传递给对应的Process来处理。
在Renderer中用RenderView表示一个web页面，每一个RenderView可以寄宿在任一一个RenderProcess中，它只是依托RenderProcess帮助它进行通信。每一个RenderProcess进程都可以有1到n个RenderView实例。
至于RenderView到底属于哪个RenderProcess，有那么几种模式：
- Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。
- Process-per-site：同域名范畴的网站放在一个进程，比如
www.google.com和www.google.com/bookmarks就属于一个域名内（google有自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行–process-per-site开启。 - Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系。用–process-per-tab开启。
- Single Process：传统浏览器的模式，没有多进程只有多线程。用–single-process开启。
Chromium进程间通信
Chromium主要使用named pipe来实现进程间通信，在Linux和OSX上则使用socketpair（一种在在计算机内部使用的socket，但不需要经过网络协议栈，打包拆包、计算校验和、维护序号和应答等）。为每个Renderer分配命名管道，以便与Browser进程通信。管道以异步模式使用，以确保两端都不会被阻塞等待另一端。
RenderProcessHost通过ChannelProxy将message放入管道，由单独的I/O进程进行过滤，然后将视图相关的message代理到Renderer的main thread，main thread就是每个Renderer管理通信的线程，渲染和大多数处理发生在Render thread上。
Chromium如何渲染页面
- WebKit：WebKit是Safari，Chromium使用的渲染引擎（Firefox 使用Gecko，IE使用Trident）。WebKit 包含WebCore排版引擎和 JavaScriptCore 引擎。分别负责排版和运行JS。Chromium不用JavaScriptCore ，其有自己的V8引擎，只用了WebCore。
- WebKit Port：WebKit的一个部分（移植或适配层），用来集成平台独立的系统服务，比如资源加载与绘图。可以将其视为WebCore的“Chromium端口”。
- Glue：将WebKit的类型转为Chromium的类型。比如WebCore::Frame转为WebFrame，命名与WebKit对象相似。把WebKit代码与Chromium分离，使WebKit代码对Chromium影响降到最小。也使得可以很容易将WebKit换成某个未来可能出现的更好的渲染引擎。
- Renderer/Renderer host：这是Chromium的“多进程嵌入层。”由它代理传递跨进程的消息和命令。你可以想象，其他的多进程浏览器也可以使用这一层，它对其他的浏览器服务没有依赖。
- WebContents：Chrome的特有层，来表示标签显示的内容。它与应用服务绑定， 例如密码管理器和history系统。
- Browser: 代表浏览器窗口，包含多个WebContent。
- Tab Helpers：可以附加到WebContents的特别对象（通过WebContentsUserData mixin）。Browser将其中的各种内容附加到它所持有的WebContents（一个用于图标集，一个用于信息栏等）。
