chrome的多进程架构

当前浏览器的问题：

没有一款浏览器能保证自己的渲染不发生crash或者挂起，也不能保证其渲染引擎的安全性非常完美。

在多任务的操作系统上，浏览器都是单用户的，这里不知道是不是在指IE。浏览器自身的问题可能引起操作系统的问题。同时某一个bug货导致整个浏览器挂掉。

多进程能够很好的防治各个进城之间的相互 影响。

Architectural overview

我们采用每一个tab一个进程的方式很好的防治了上述的问题，我们将负责管理UI、tabs和插件进程的称为browser进程即主进程。每一个TAb对应一个render进程，或者叫做renderers，renderers用wekit来渲染html页面。

Managing render processes

每一个render进程含有一个RenderProcess 对象，RenderProcess 用来维护一些全局的状态和主进程的通信。主进程同时维护了RenderProcessHost 来和RenderProcess 对应，同时，RenderProcessHost 维护的主进程的一些状态及和render进程的通信，主进程和子进程的通信过程是Chromium's IPC system.

Managing views

每一个子进程通过RenderProcess来维护和管理了一个或者多个renderview对象，每一个renderview对应一个tab的content。与renderprocess对应的RenderProcessHost维护了多个RenderViewHost ，而每个RenderViewHost 到与子进程的renderview是对应的。每一个renderview都有对应的ID，用来区分同一个子进程中的多个view。这个viewid在子进程内是唯一的但是在主进程就不是了。因此要确定一个view，不仅需要id还需要RenderProcessHost。browser的某一个tab，要发信息到内核，则可以通过RenderViewHost ，renderviewhost可以找到对应的RenderProcessHost，再到renderpress最后到renderview。

Components and interfaces

In the render process:

每一个子进程只有一个RenderProcess 对象，主进程和子进程通过RenderProcessHost 和RenderProcess 及ipc完成通信

renderview和renderpresshost对应

In the browser process:

Browser 对象代表的是a top-level browser window，在主进程也就是browser进程，只有一个RenderProcessHost ，但其对应了每一个renderprocess

RenderViewHost 用来和子进程通信，对应的是RenderView；RenderWidgetHost 用来绘制RenderWidget

 

在主进程RenderProcessHost 对象代表了一条主进程和子进程的通道

Sharing the render process ：

通常情况下，在一个新的进程中打开一个窗口或者创建一个tab，都会创建一个对应的子进程。但是在某些情况下则需要tab和windows共享进程。如：windows.open或者我打开一个应用程序的登陆框，只有登录了才可以下一步操作。

Detecting crashed or misbehaving renderers

如果子进程的句柄不存在了则tab崩溃了