Chromium（二）Multi-process Architecture

今天团建，中午吃了太多，下午回来只工作了一会儿... 闲言少叙，开始今天的学习。

Multi-process Architecture

为什么使用多进程结构：

1.渲染进程很难保持永远不挂。

2.单个进程要是挂了整个程序就完蛋。

3.进程间是相互隔离的，即使一个挂了也不影响其他的。

结构总览：

主进程Browser，Tab进程Render（多个）。Render使用Blink(开源)解释和布局HTML。

管理Render进程

每个Render进程都有一个全局的RenderProcess对象用来与浏览器进程交互。浏览器为每个Render维持一个RenderProcessHost用来管理浏览器状态和与Render进程通信。浏览器与Render进程通信使用的是Chromium's IPC system进程间通信系统（后面也要学习）。

管理Views

每个Render进程使用RenderProcess维持一个或多个RenderView对象，RenderProcessHost维持RenderViewHost与Render中的RenderView通信,每个Browser中的RenderViewHost对应一个Render中的RenderView。所以如果Browser希望与Render进行通信可以通过RenderViewHost，通过RenderViewHost可以拿到RenderProcessHost发送消息给RenderProcess然后根据RenderViewID再将消息发送给对应的RenderView。反过来同理。IPC是发生在RenderProcess和RenderProcessHost之间的。

共享Render进程

打开一个新的Tab，browser通常会创建一个新的进程和一个RenderView。

但是有时一个Render进程会被tab和window共享。比如用js的window.open打开有个窗口，我们重复使用被打开Window的render进程。如果进程数太多的话，也有策略将一个新建的tabs给一个已经存在的进程。这些策略在ProcessModel中描述点击打开链接

检测Render崩溃

Browser通过IPC监控Render的Handle，如果有信号通知这些handle Render进程崩溃，我们将看到sad tab通知用户。

Render进程的沙盒

Render作为一个进程，我们通过沙盒来限制这个进程访问系统资源。比如 balabalabala

提供备用内存

使用多进程，可以直接将隐藏在后面的Tab的Render进程设置为低优先级，windows会自动回收内存释放出来，将内存提供给高优先级的使用。如果是单进程，释放空闲内存就会比较麻烦，因为比较难分辨出哪个变量是在显示的哪个是不显示的，这样既浪费了内存，又降低了性能。

今天翻译了一下文档，对这些有个大致的了解吧。明天学习

How Chromium Displays Web Pages