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会自动回收内存释放出来,将内存提供给高优先级的使用。如果是单进程,释放空闲内存就会比较麻烦,因为比较难分辨出哪个变量是在显示的哪个是不显示的,这样既浪费了内存,又降低了性能。
今天翻译了一下文档,对这些有个大致的了解吧。明天学习