本文为作者学习Chromium开发文档所做的笔记，类似于主要文档翻译，穿插一些注释和个人理解。干货不多，请见谅。
本篇参考文档 Multi-process Architecture
问题的引入
- 用不崩溃和挂起的渲染引擎（Rendering engine）几乎不存在（nearly
impossible），完全安全的渲染引擎也几乎不存在。
- 旧式浏览器（类似旧式操作系统：单用户/多任务协作，某应用损坏导致系统崩溃）中的某个网页问题或者插件bug可能导致整个浏览器和所有标签页崩溃。
- 新式的系统将应用之间使用进程进行隔离，某一应用崩溃不会导致其他应用或整个系统崩溃，用户之间的数据管理也更加严格。
多进程架构总览
- 为不同的标签使用不同的进程，以防止渲染引擎的bug导致整个应用的崩溃。
- 限制渲染引擎之间的访问，对操作系统的访问，以及对其他用户数据的访问。
- 主进程主要负责运行UI，管理标签和插件进程。称为浏览器进程或浏览器。
- 标签进程使用WebKit开源排版引擎（layout
engine，与渲染引擎为同一wiki词条）进行解释和HTML排版。称为渲染器或者渲染器进程。
注：2013年
Google从WebKit分支出Blink引擎，Chrome和Opera新版本均采用blink。
管理渲染器进程
- 每个渲染器都拥有一个全局的RenderProcess对象，用来管理与浏览器府进程进行通信和维护全局状态。
- 浏览器为每个渲染器维护一个相应的RenderProcessHost对象，用来管理浏览器状态和与渲染器通信
- 渲染器和浏览器之间使用Chromium‘s
IPC system进行通信。
管理视图（views）
- 每个渲染其拥有一个或多个RenderView对象，由RenderProcess控制，对应内容中的标签。
多个view对象情况：进程过多需要合并，使用windows.open等语句打开的标签或者其他需要在两个标签之间同步的情况等。
- 浏览器中对应的RenderProcessHost维护一个RenderViewHost对象对应于渲染器中的每个view。
- 每个view都有一个ID，用来在同一渲染器中区分view，该Id在渲染其中是唯一的，但是在浏览器中不唯一，所以识别一个view需要一个RenderProcessHost对象和一个view
ID。
- 浏览器和渲染器中特定标签的通信需要通过RenderViewHost对象，这些对象明白如何将信息从RenderProcessHost传递给RenderProcess后再传递给RVenderiew。
组件和接口
共享渲染器进程
- 一般来说，每个窗口和标签都是在新进程中打开的，浏览器会创建一个新进程并且指示创建一个RenderView.
- 但有时有必要或者有意愿在标签或窗口之间共享。给新标签或窗口制定已经存在的进程。
- 一个网络应用使用windows.open打开一个新窗口，希望能与该窗口实时通信。
- 进程总数太大。
- 已经有一个进程打开了相同的网址。 更多策略说明在Process
Models.
检测崩溃或出错的渲染器
- 每个连接到浏览器的IPC连接都监视进程句柄。当句柄发送信号时，渲染器已经崩溃，而且对应的标签都会被通知。
- 之后浏览器显示“sad tab”并且通知用户，由用户决定刷新或者重新导航。当崩溃发生时，进程就被杀死并写创建新进程。
为渲染器添加沙盒
- 由于WebKit晕次那个在分开的进程中，所以浏览器可以限制其访问系统资源。
- 保证渲染器只能通过浏览器父进程访问网络。
- 使用操作系统内置的权限来限制访问操作系统的文件系统。
- 限制进程访问用户显示和相关的对象，防止渲染其打开新窗口或者获取按键信息。
内存回收
- 隐藏标签的进程优先级低。
- 类似于windows的内存管理(低优先级的进程内存会被交换到硬盘上)，浏览器也会在必要时进行相似的操作，导致相关标签的性能降低。
- 在低内存环境下，切换到常用标签会比切换到不常用的标签快（内存够用时不会发生此类情况）。
Chromium文档学习（一）－－多线程结构
原文：http://www.cnblogs.com/hufozhu/p/3549787.html
