原文地址:http://www.chromium.org/developers/design-documents/multi-process-architecture
浏览器引擎不可能绝对稳定,也不可能绝对安全。
某种程度上,当前的Web浏览器类似于之前单用户、多任务协同工作的操作系统。
2、结构概述
为了减少浏览器内核的bug,我们将不同的Tab页用不同的进程隔离起来。进程间的访问受限,对系统其他部分的访问也受限。这使得web浏览器获得了类似内存保护和访问控制给操作系统带来的好处。
我们将UI和管理Tab页、插件进程的主进程称为browser进程或者browser。同样的,一个特定tab页对应的进程被称为render进程或者renderers。这些renderers使用WebKit开源布局引擎来解释和布局HTML。
4、管理视图
RenderProcess
管理,对应着tab页里的内容。
RenderProcessHost
为每一个View维护一个RenderViewHost。用ID号来标识同一个Render里不同的View。ID值在一个Render里是不同的,但不保证在Browser里不同,所以要需要一个RenderProcessHost和一个ViewID才能定位到一个View。Browser和特定tab页里的特定view通过这些RenderProcessHost对象来通信,它们知道怎样从RenderProcessHost发送消息到 RenderProcess并最终作用于RenderView
。
5、组件和接口
- RenderProcess(Render端)维持着与RenderProcessHost(Browser端)间IPC通信。每个render进程只有一个RenderProcess对象,这就是browser和所有的renderers间通信的方式。
- Renderview(Render端)通过RenderProcess(Render端)以及WebKit嵌入层和RenderViewHost (Browser端)通信。Renderview对象代表一个tab页的内容或者一个弹出窗口。
- Browser对象代表一个最高级别的的浏览器窗口。
- RenderProcessHost(Browser端)对象代表一个 Browser和Renderer间的IPC连接。每个render进程对应browser进程里的一个RenderProcessHost。
- RenderViewHost(Browser端)对象将同远端Renderview(Render端)的通信封装进内部,RenderWidgetHost(Browser端)对象控制着RenderWidget(Render端)的输入和绘制。
6、共享render进程
RenderView
(Render端)。
7、探测未正常运行的Renderers
8、将renderer放入沙盒
Renderers在不同的线程中运行,自然而然将隐藏的tab页置为低优先级。通常,Windows操作系统将进程内存放入“可用内存”池来减少内存占用。在内存吃紧的情况下,WIndows会将低优先级的内存置换到硬盘,确保用户可见的程序交互更顺畅。我们可以将这种规则应用到隐藏的tab页中。如果必要,当一个render进程没有高级别tab页的时候,可以暗示操作系统将render的工作集内存置换到硬盘里。我们逐渐的释放这些内存,因为工作集内存的释放帮随着切换tab页性能变差的后遗症。这意味着,用户切回刚用过的标签页比切回很久没有使用的标签页工作集内存准备好的几率更高。如果用户有足够的内存跑起来所有的程序,将不会进行内存置换。
Windows只在必要的时候这么做,所以内存足够的时候将不会有性能忧虑。