《Multi-process Architecture》浏览器多进程架构 笔记

学习资料：《Multi-process Architecture》

学习进度跟踪

• 2021.06.12晚。在 《Life of a pixel》学习笔记 中了解过chrome多进程架构有哪些多进程，以及为什么是多进程架构。这篇document可以帮助我更详细地了解！
• 2021.06.13下午。官方文档介绍的架构级顶层的内容，没有过多的实现细节。对于我这样的小白去理解和学习，是非常有帮助的。Finish！

---

Problem

不可能有一个完美，安全，不crash的render engine

对于浏览器进程来说，如果是单进程多线程的操作，比如一个plugin的报错，就会导致整个浏览器崩溃，显然是不合理的

现代操作系统是健壮的，因为每个进程之间是互相独立了，A进程崩溃，并不会影响其他进程 或者 操作系统

---

架构概览

每一个标签页是一个新的Process，这样可以避免因为Render Engine Crash导致的影响。同时，也限制Render Process对其他Process的资源访问，在一定程度上，通过内存保护和访问控制，给OS带来了好处

运行UI和管理Plugin Process，一般被称为Browser Process。Tab Process也称为Render Process

---

管理Render Process

每一个Render Process有一个进程全局变量，叫RenderProcess Object，通过IPC（Inter-Process Communication）Render Process与Browser Process的数据交互。对于每一个RenderProcess，在Browser Process中会有一个对应的RenderProcessHost

---

管理Views

每一个Render Process通过该进程唯一的RenderProcess Object，管理 一个或者多个 Render View。这些View和对应的Tab相对应（TODO）。RenderProcess Object对应的RenderProcessHost下也一一对应了RenderViewHost。Render Process中的每一个RenderView都有一个该进程唯一的ID

对于Browser Process一个ID还不够，因此还需要RenderProcessHost。有点像一层一层进行管理

通过RenderViewHost对象，可以在Browser Process中指定一个tab页，并通过 Browser Process的RenderViewHost Object 进行数据传输

---

组件和接口

Render Process

• Render Process通过RenderProcess Object 使用 IPC进程间通信，和Browser Process交换数据
• Render View通过RenderProcess Object，和BrowserProcess对应的RenderViewHost Object进行数据通信，以及WebKit layer的数据通信。Render View Object对应一个标签页的Render Conent

Browser Process

• Browser Object代表浏览器的最顶层的应用窗口
• RenderProcess Host代表单个标签页 和 对应Render Process交互。他们是一一对应的关系
• RenderView Host同理

---

共享Render Process

通常来说，一个新的标签页会对应一个新的Render Process，Browser Process指示Render Process 创建新的RenderView。有时候RenderProcess之间需要共享性能，提高效率，类似联合编译

---

检测崩溃和异常行为

Render Process如果崩溃了，会通过IPC给Browser Process 发送崩溃协议。Browser发现对应的渲染进程挂了，那就再起一个

---

沙盒渲染

通过沙盒环境，限制Render Process的权限仅能通过Browser Process执行，保证程序安全，防止恶意程序破坏系统

---

回收内存

如果一个tab不被用户所看到，那么可以减低它的内存开销。简单来说，更合理地分配系统内存

---

插件进程

插件会单独起进程