浏览器架构的发展

[nfssuzukaze]

1. 单进程浏览器时代

典型的单进程浏览器就是 IE6 ，对于单进程浏览器来说，浏览器所有的功能模块都运行在同一个进程中，造成了许多的问题，比如

• 不稳定

  早期的插件与渲染引擎模块都是很不稳定的，如果有模块的崩溃而导致线程的崩溃，而线程的崩溃也会导致进程的崩溃，使得整个浏览器就此崩溃

• 不流畅

  • 线程被占用

  对于一个单进程浏览器的一个线程来说，它负责处理的事情有很多。例如，对于网页 a 的一个脚本运行需要大量的时间，当网页 a 的脚本执行时，它会独占内存，直到网页 a 的脚本执行完毕之，网页 b 的脚本都不会执行。这给用户的体验是及其之差的

  • 内存泄漏

  在内存不能完全回收的情况下，浏览器的使用时间越长，则内存占用越高，浏览器会变得越慢

• 不安全

  • 插件

  浏览器的插件通常是使用 C/C++ 编写的，通过插件可以获取到 OS 的任意资源。当在浏览器上运行一个插件的时候，那么这个插件也可以操作你的电脑。如果插件的恶意的话，那么就会引发安全问题

  • 页面脚本

  页面脚本可以通过浏览器的一些漏洞来获取系统权限，获取了系统权限之后同样可以引发安全问题

2. 多进程浏览器时代

早期的 Chrome 浏览器的进程架构中有 3 个进程类型，分别是渲染进程，插件进程 和 浏览器主进程

• 解决了不稳定的问题

  由于进程之间是相互隔离的，所以一个进程的崩溃一般不会导致其他进程的崩溃，这就解决了浏览器不稳定的问题

• 解决了不流畅的问题

  • 即便有一个极其耗时的脚本在运行，其阻塞的也只是那一个页面的渲染进程，并不会影响到浏览器和其他页面
  • 关闭了一个页面，那么这个页面的渲染进程也会被关闭，其所占用的所有内存都会被浏览器回收

• 解决了安全问题

  多进程架构的额外好处是可以使用安全沙箱：沙箱里面的程序可以运行，但是不能在硬盘上写入任何数据，也不能在敏感位置读取任何数据，例如文档和桌面。

  Chrome 把插件进程和渲染进场锁在沙箱里面，这样即使在渲染进程或插件进程里执行了恶意的程序，它也无法突破沙箱去获取系统权限

目前的 Chrome 浏览器的进程架构中存在 5 个进程类型

• 渲染进程(Render Process)

  排版引擎 Blink 和 JavaScript 引擎 V8 都运行在该进程中。默认情况下，Chrome 会给每个 Tab 标签创建一个渲染进程（但是如果是“同一站点”的话，则多个 Tab 也只会占用一个进程）。为了安全起见，每个渲染进程都运行在沙箱模式下

• 插件进程(Plugin Process)

  因为插件容易崩溃，所以通过插件进程来隔离插件，以保证插件的崩溃不会对页面和浏览器产生影响

• 网络进程(Network Process)

  从浏览器进程里独立出来的，主要负责网络资源的加载

• 浏览器主进程(Browser Process)

  主要负责界面显示、用户交互、子进程管理，同时提供存储等功能

• GPU进程(GPU Process)

  处理来自不同 Tab 的渲染请求并把它在同一个界面上画出来

同一站点：指的是一个新的 Tab 是在一个旧的 Tab 中打开的，且根域名与协议都相同的网页

浏览器多进程架构的缺点

• 更高的资源占用

  因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源

• 更复杂的体系架构

  浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了

为解决这些问题，在 2016 年，Chrome 官方团队使用“面向服务的架构” (SOA) 的思想设计了新的 Chrome 架构。也就是说 Chrome 整体架构会朝向现代操作系统所采用的“面向服务的架构” 方向发展，原来的各种模块会被重构成独立的服务（Service），每个服务（Service）都可以在独立的进程中运行，访问服务（Service）必须使用定义好的接口，通过 IPC 来通信，从而构建一个更内聚、松耦合、易于维护和扩展的系统，更好实现 Chrome 简单、稳定、高速、安全的目标

Chrome 最终要把 UI、数据库、文件、设备、网络等模块重构为基础服务，类似操作系统底层服务。

同时 Chrome 还提供灵活的弹性架构，在强大性能设备上会以多进程的方式运行基础服务，但是如果在资源受限的设备上，Chrome 会将很多服务整合到一个进程中，从而节省内存占用