作为前端cv仔和浏览器打交道是最多的，浏览器对我们来说可以说是个黑盒，今天我们就来聊聊浏览器的架构。
首先了解一下必要的知识进程和线程。

进程与线程

  1. 进程是资源分配的最小单位,线程是程序执行的最小单位。
  2. 同一进程下的线程共享全局变量、静态变量等数据，而进程之间的通信需要以通信的方式（IPC)进行。
  3. 进程有自己的独立地址空间，每启动一个进程，系统就会为它分配地址空间，建立数据表来维护代码段、堆栈段和数据段，而进程共享进程中的数据的，使用相同的地址空间；
  4. 多进程程序更健壮，多线程程序只要有一个线程死掉，整个进程也死掉了，而一个进程死掉并不会对另外一个进程造成影响，因为进程有自己独立的地址空间。

单进程浏览器时代

顾名思义，单进程浏览器是指浏览器所以模块都运行再同一个进程里，这些模块包含了网络、插件、JavaScript 运行环境、渲染引擎和页面等。
单进程浏览器的架构如下图所示👇

如此多的功能模块运行在一个进程里，肯定有着不足的：

  1. 不稳定性：只要一个线程崩溃，这个进程就崩溃，浏览就用不了了。
  2. 不流畅： 多个任务共用一个线程，比如页面线程。
  3. 不安全：没有沙箱机制。

多进程浏览器时代

早期多进程架构

从图中可以看出，Chrome 的页面是运行在单独的渲染进程中的，同时页面里的插件也是运行在单独的插件进程之中，而进程之间是通过 IPC 机制进行通信（如图中虚线部分）

  • 解决早期浏览器不稳定问题：由于进程是相互隔离的，所以当一个页面或者插件崩溃时，影响到的仅仅是当前的页面进程或者插件进程，并不会影响到浏览器和其他页面，这就完美地解决了页面或者插件的崩溃会导致整个浏览器崩溃，也就是不稳定的问题。
  • 解决早期浏览器不流畅问题：JavaScript 也是运行在渲染进程中的，所以即使 JavaScript 阻塞了渲染进程，影响到的也只是当前的渲染页面，而并不会影响浏览器和其他页面，因为其他页面的脚本是运行在它们自己的渲染进程中的。所以当我们再在 Chrome 中运行上面那个死循环的脚本时，没有响应的仅仅是当前的页面。对于内存泄漏的解决方法那就更简单了，因为当关闭一个页面时，整个渲染进程也会被关闭，之后该进程所占用的内存都会被系统回收，这样就轻松解决了浏览器页面的内存泄漏问题。
  • 解决早期浏览器不安全问题：用多进程架构的额外好处是可以使用安全沙箱，你可以把沙箱看成是操作系统给进程上了一把锁，沙箱里面的程序可以运行，但是不能在你的硬盘上写入任何数据，也不能在敏感位置读取任何数据，例如你的文档和桌面。Chrome 把插件进程和渲染进程锁在沙箱里面，这样即使在渲染进程或者插件进程里面执行了恶意程序，恶意程序也无法突破沙箱去获取系统权限。

目前多进程架构

从图中可以看出，最新的 Chrome 浏览器包括：1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程。
下面我们来逐个分析下这几个进程的功能👇

  • 浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
  • 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
  • GPU进程。Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
  • 网络进程。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
  • 插件进程。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

多进程带来的问题：

  1. 更高的资源占用因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
  2. 更复杂的体系架构浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了

面向未来的架构

为了解决上面的问题，在2016年，Chrome官方团队使用“面向服务的架构”（Services Oriented Architecture，简称 SOA）的思想设计了新的 Chrome 架构Chrome 最终要把 UI、数据库、文件、设备、网络等模块重构为基础服务，类似操作系统底层服务，下面是 Chrome“面向服务的架构”的进程模型。

试题

  • 为什么单进程浏览器当时不可以采用安全沙箱？
    如果一个进程使用了安全沙箱之后，该进程对于操作系统的权限就会受到限制，比如不能对一些位置的文件进行读写操作，而这些权限浏览器主进程所需要的，所以安全沙箱是不能应用到浏览器主进程之上的。
  • 打开Chrome浏览器一个Tab页面，至少会出现几个进程？
    最新的Chrome浏览器包括至少四个:1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程,当然还有复杂的情况；
  1. 页面中有iframe的话,iframe会单独在进程中
  2. 有插件的话，插件也会开启进程
  3. 多个页面属于同一站点，并且从a打开b页面，会共用一个渲染进程
  4. 装了扩展的话，扩展也会占用进程
    这些进程都可以通过Chrome任务管理器来查看
  • 即使如今多进程架构，还是会碰到单页面卡死的最终崩溃导致所有页面崩溃的情况，讲一讲你的理解？
    Chrome的默认策略是，每个标签对应一个渲染进程。但是如果从一个页面打开了新页面，而新页面和当前页面属于同一站点时，那么新页面会复用父页面的渲染进程。官方把这个默认策略叫process-per-site-instance。
    更加简单的来说，就是如果多个页面符合同一站点，这几个页面会分配到一个渲染进程中去,所以有这样子的一种情况,一个页面崩溃了，会导致同一个站点的其他页面也奔溃，这是因为它们使用的是同一个渲染进程。
    它们在一个渲染进程中的话，它们就会共享JS执行环境，也就是A页面可以直接在B页面中执行脚本了。