探索现代浏览器架构与原理（一）｜现代浏览器的架构演变-烟雨网

本文是探索现代浏览器架构与原理专栏的开篇，今天跟大家一起探索现代浏览器的架构演变。

一些基本概念

在深入探索浏览器架构之前，我们先来快速复习下以下计算机基础知识：

CPU & GPU

CPU：中央处理器，类似流水线一样串行的处理任务

GPU：图形处理器，数量多，并行计算能力强

进程 & 线程 & 内存空间

进程和 线程 这两个词在中文上比较接近，很多刚接触计算机的同学经常会搞混。因此我在这里推荐大家去记住他们的英文表达，更好区分一些。

进程（process）

启动一个程序的时候，操作系统会为该程序创建一块私有的内存空间，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。当程序关闭时，对应的内存空间也会被系统释放掉。

线程（thread）

一个进程中可以有一个或多个线程，线程之间是共享进程中的数据。

一个进程中可以有多个线程

每个进程都有一块私有的内存空间

多进程

多进程，顾名思义就是有多个进程。多进程模式有以下特点·：

进程之间是相互隔离的
进程之间需要通过 IPC 通信（管道、信号、消息队列、共享内存、socket 等）
一个进程挂掉了并不会影响到其他进程

现代浏览器的架构演变

有了前面计算机基础概念的知识储备后，接下来我们开始探索现代浏览器架构的演变。

单进程架构

在 08 年之前，市面上的浏览器基本都是单进程架构。
单进程架构的意思就是浏览器的所有功能模块都运行在同一个进程里，包括：

网络
插件
JS 运行环境
渲染引擎
页面

这种单进程架构存在什么问题呢？大概分为以下三个方面：

不稳定：早期的视频、游戏是需要借助插件来实现的，一个插件崩溃可能就会引起浏览器的崩溃
不流畅：页面渲染、JS、插件等都在页面线程中
不安全：插件可以获取你操作系统中的任意资源

正是因为浏览器的单进程架构存在上述种种问题，导致早期浏览器总给人留下一种 动不动就崩溃 的体验很差的印象。

为了解决体验上的痛点，多进程架构应运而生了。

下面我会和大家一起主要探索 Chrome 浏览器的多进程架构

Chrome 多进程架构 —— 初期

2008 年， Chrome 诞生了。Chrome 从诞生之初就跳过了单进程架构，直接开启多进程架构模式。
它最早期的多进程架构是这样的：

主要有三个进程：

浏览器主进程：包含了浏览器的绝大部分功能
渲染进程：包含了前端同学接触到最多也是最熟悉的部分能力 – 解析、渲染、JS 执行等等
插件进程：这里需要特别注意，插件进程是 Plugin Process，与现在常说的插件（Extension）不是一个东西来的，后面我会详细讲一下二者的区别

可以看到，渲染进程运行在 Sandbox 里，浏览器限制了它读取数据以及获取操作系统权限的能力。

同时也可以看到，进程之间是通过 IPC 来通信的。

Chrome 多进程架构 — 优化

Chrome 的多进程架构当然也不是一成不变的。Chrome 团队致力于对其架构做各种优化，优化后的架构大致如下：

Chrome浏览器会有一个浏览器进程（browser process），这个进程会和其他进程一起协作来实现浏览器的功能。

上图中各个进程之间的分工如下：

进程	分工
Browser 主进程	控制浏览器的 “chrome” 部分，包括导航栏，书签，前进后退刷新等等。同时还负责操作网络请求、文件读写等我们看不见的部分。
Renderer 渲染进程	负责控制 tab 内网页展示相关的所有工作
Plugin 插件进程	负责控制网页使用的所有插件，比如 flash
GPU 进程	负责独立于其他进程的 GPU 任务。需要处理来自不同 tab 的渲染请求，并在同一个界面上渲染出来

除了上面列出来的进程，Chrome还有很多其他进程在工作，例如扩展进程（Extension Process）和实用程序进程（Utility process）。

大家可以在 Chrome 里，通过 右上角 -> 更多工具 -> 任务管理器 查看目前你的 Chrome 在正运行的进程：

站点隔离

Chrome 同时还会尽可能为每一个 tab 甚至是页面里面的每一个 iframe 都分配一个单独的渲染进程。

这样做的原因是如果一个 tab 只有一个进程的话，不同站点的 iframe 都会跑在这个进程里面，这也意味着它们会共享内存，这就有可能会破坏同源策略。

而进程隔离是隔离网站最好最有效的办法了。因此在Chrome 67 版本之后，桌面版的 Chrome 会默认开启网站隔离功能，这样每一个跨站点的 iframe 都会拥有一个独立的渲染进程。

Plugin 和 Extension

前端同学经常会接触到很多浏览器插件。
而前面我们也提到有插件进程（Plugin Process）和拓展程序进程（Extension Process），那么我们常说的浏览器插件到底属于哪一种呢？

我们来看下二者之间的区别：

Plugin: flash 等

类似操作系统中的驱动程序，偏底层
通过过调用 Webkit 内核的 API 来扩展内核功能的一种组件，工作在内核层面，理论上可以用任何一种生成本地二进制程序的语言开发，比如 C/C++
通过 chrome://plugins/ 访问（目前已被废弃）

Extension: FeHelper 等

类似操作系统中的工具类程序，偏上层
指的是通过调用 Chrome 提供的 Chrome API 来扩展浏览器功能的一种组件，工作在浏览器层面，使用 HTML + Javascript 语言开发
通过 chrome://extensions/ 访问

因此可以确定，现阶段我们常常提到的 FEHelper 等浏览器插件，实际上更准确来说应该属于浏览器拓展程序。

Chrome 多进程架构 — SOA

正如前面所说，Chrome 团队一直致力于探索浏览器架构的优化。在 2016 年他们推出了新的多进程架构理念，面向服务的多进程架构：Services Oriented Architecture，简称 SOA。

原来的浏览器本身的各种模块会被重构成独立的服务（Service），每个服务（Service）都可以在独立的进程中运行

这样做的主要原因是让 Chrome 在不同性能的硬件上有不同的表现。当 Chrome 运行在一些性能比较好的硬件时，浏览器进程相关的服务会被放在不同的进程运行以提高系统的稳定性。相反如果硬件性能不好，这些服务就会被放在同一个进程里面执行来减少内存的占用。

在硬件性能较差的设备上：

在硬件性能较好的设备上：

SOA 架构是现代浏览器架构现在与未来的趋势，相信 Chrome 架构未来的探索方向也会继续往 SOA 的方向深入。

现代浏览器多进程架构的优劣

优点

前面我们一起探索了现代浏览器架构的演变，那么对于目前流行的多进程架构，它的优点可以总结为以下两点：

更稳定： 一个 tab 就是一个渲染进程，当一个 tab 挂掉时，不会影其他 tab。
更安全： 因为操作系统可以提供方法让你限制每个进程拥有的能力，所以浏览器可以让某些进程不具备某些特定的功能。例如，由于tab渲染进程可能会处理来自用户的随机输入，所以 Chrome 限制了它们对系统文件随机读写的能力