宏观视角下的浏览器
线程 VS 进程
多线程可以并行处理任务，但是线程是不能单独存在的，它是由进程来启动和管理的。
一个进程就是一个程序的运行实例。详细解释就是，启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。
线程是依附于进程的，而进程中使用多线程并行处理能提升运算效率。
进程和线程之间的关系
- 进程中的任意一线程执行出错，都会导致整个进程的崩溃。
- 线程之间共享进程中的数据。
- 当一个进程关闭之后，操作系统会回收进程所占用的内存。
- 进程之间的内容相互隔离。
单进程浏览器时代的问题
不稳定
- 早期浏览器需要借助于插件来实现诸如 Web 视频、Web 游戏等各种强大的功能，但是插件是最容易出问题的模块，并且还运行在浏览器进程之中，所以一个插件的意外崩溃会引起整个浏览器的崩溃。
- 除了插件之外，渲染引擎模块也是不稳定的，通常一些复杂的 JavaScript 代码就有可能引起渲染引擎模块的崩溃。和插件一样，渲染引擎的崩溃也会导致整个浏览器的崩溃。
不流畅
- 单个Tab页的死循环会牵扯整个浏览器的卡顿、失去响应。
- 复杂页面的打开和关闭，不能完全回收内存，随着使用时间越来越长，浏览器会变得越来越慢。
不安全
- 插件可以使用
C/C++等代码编写，通过插件可以获取到操作系统的任意资源。 - 至于页面脚本，它可以通过浏览器的漏洞来获取系统权限。
多进程浏览器时代
目前多进程架构
浏览器主进程
主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
渲染进程*n
核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink和JavaScript 引擎 V8都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
GPU进程
其实，Chrome 刚开始发布的时候是没有GPU进程的。
而 GPU 的使用初衷是为了实现3D CSS的效果，只是随后网页、Chrome 的 UI 界面都选择采用GPU来绘制，这使得GPU成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了GPU 进程。
网络进程
主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
插件进程*n
主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。
如何解决单进程架构中遇到的问题
如何解决不稳定的问题？
由于进程是相互隔离的，所以当一个页面或者插件崩溃 时，影响到的仅仅是当前的页面进程或者插件进程，并不会影响到浏览器和其他页面。
如何解决不流畅的问题？
JavaScript 也是运行在渲染进程中的，所以即使 JavaScript 阻塞了渲染进程，影响到的也只是当前的渲染页面，而并不会影响浏览器和其他页面。
对于内存泄漏的解决方法那就更简单了，因为当关闭一个页面时，整个渲染进程也会被关闭，之后该进程所占用的内存都会被系统回收。
如何解决不安全的问题？
采用多进程架构的额外好处是可以使用安全沙箱，你可以把沙箱看成是操作系统给进程上了一把锁，沙箱里面的程序可以运行，但是不能在你的硬盘上写入任何数据，也不能在敏感位置读取任何数据，例如你的文档和桌面。
Chrome 把插件进程和渲染进程锁在沙箱里面，这样即使在渲染进程或者插件进程里面执行了恶意程序，恶意程序也无法突破沙箱去获取系统权限。
多进程带来的问题
更高的资源占用
因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
更复杂的体系架构
浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。
未来面向服务的架构
最初的浏览器都是单进程的，它们不稳定、不流畅且不安全，之后出现了 Chrome，创造性地引入了多进程架构，并解决了这些遗留问题。
随后 Chrome 试图应用到更多业务场景，如移动设备、VR、视频等，为了支持这些场景，Chrome 的架构体系变得越来越复杂，这种架构的复杂性倒逼 Chrome 开发团队必须进行架构的重构，最终 Chrome 团队选择了面向服务架构（SOA）形式，这也是 Chrome 团队现阶段的一个主要任务。
为了解决这些问题，在 2016 年，Chrome 官方团队使用面向服务的架构（Services Oriented Architecture，简称SOA）的思想设计了新的 Chrome 架构。
也就是说Chrome 整体架构会朝向现代操作系统所采用的面向服务的架构方向发展，原来的各种模块会被重构成独立的服务（Service），每个服务都可以在独立的进程中运行，访问服务必须使用定义好的接口，通过IPC来通信，从而构建一个更内聚、松耦合、易于维护和扩展的系统，更好实现Chrome简单、稳定、高速、安全的目标。
Chrome 最终要把 UI、数据库、文件、设备、网络等模块重构为基础服务。 
目前 Chrome 正处在老的架构向服务化架构过渡阶段，这将是一个漫长的迭代过程。
Chrome 正在逐步构建 Chrome 基础服务（Chrome Foundation Service），如果认为Chrome 是“便携式操作系统”，那么 Chrome 基础服务便可以被视为该操作系统的“基础”系统服务层。
同时 Chrome 还提供灵活的弹性架构，在强大性能设备上会以多进程的方式运行基础服务，但是如果在资源受限的设备上，Chrome 会将很多服务整合到一个进程中，从而节省内存占用。 