预备知识
要想了解浏览器架构的发展历史，我们首先需要了解一下进程及线程的特性
基础知识
进程可以理解为一个运行中的程序，线程则存在于进程中。
进程是系统进行资源分配的最小单元，也就是说，线程无法单独的获取系统的资源，需要使用其所在的进程的资源。
线程由进程创建而存在，当进程销毁时，正在运行的线程也会自动销毁
单线程 vs 多线程
一个进程处理任务时，可以采用单线程也可以采用多线程，对于多核属于标配的时代，使用多线程处理程序，可以极大的提升处理性能。
比如，我们要计算下面三个表达式的值，并显示出结果来
A = 1 + 2
B = 20 / 5
C = 7 + 8
console.log(A, B, C)
使用单线程处理时，我们可以把这个过程拆分为四个任务：
- 任务1 计算 A = 1 + 2
- 任务2 计算 B = 20 / 5
- 任务3 计算 C = 7 + 8
- 任务4 显示最后的结果
如果采用多线程，经过分析，我们发现这四个步骤中，前三个任务之间是独立的，可以并行执行，第四个任务则需要等待前三个任务结束后，方能执行。因此我们可以将其分成三个线程来处理。
三个线程分别处理前三个任务中的一个，然后选择一个线程来处理最后一个任务就好。
但是有一点需要注意，只要有一个线程奔溃了，那么整个进程都会奔溃。
通信
线程间通信
同一个进程的线程之间可以共享进程的公共数据，以便于进行读写操作。
进程通信
对于进程间通信，则略为复杂一些，需要使用IPC进行通信（图中黑色虚线）。
要点总结
从以上的知识点中，提取出对下文有直接影响的几个点。
1. 进程中的任意一个线程出错，都会导致整个进程的奔溃
2. 线程之间共享进程中的数据
�3. 当一个进程关闭后，操作系统会回首进程占用的内存
进程关闭后，系统会回收所有的资源，哪怕是由于操作不当，引起的内存泄露问题，内存也会被正确回收。
比如早期的ie浏览器，支持很多插件，而这些插件很容易造成内存泄露，这意味着只要浏览器开着，内存 占用就会越来越多，所以需要关闭浏览器，重新打开，从而让这些内存被回收掉
4. 进程之间互相隔离
由于进程之间是互相隔离的，从而保证了进程的独立性。当一个进程发生奔溃时，不至于影响其他进程。进程之间需要通信的话，可以使用IPC技术
浏览器架构进化史
由于chrome拥有着极大的市场占有率，在多进程时代我们将以chrome为案例进行解析。
单进程时代
故名思义，单进程浏览器就是将所有功能都放在一个进程中来实现。
在该浏览器进程中，采用多线程技术，将不同的功能使用不同的线程来实现，比如网络线程、页面线程等。
如何多的功能运行在同一个进程中，会导致浏览器不稳定、不流畅、不安全等问题。
问题1：不稳定
浏览器中的许多强大功能需要借助于插件来实现，但是插件是第三方提供的，非常容易出现问题。
同时，除去插件容易出现问题，页面线程中的javascript也非常容易出现问题。
从线程和进程之间的描述中，可以知道，一个线程的奔溃，会导致整个进程的奔溃。
问题2: 不流畅
这个不流畅所指的不仅仅是当前页面的不流畅，还有整个浏览器的不流畅。
从上图中，我们得知，所有页面的渲染模块，js的执行模块、插件都运行在同一个线程中，这也就是说，同一个时刻只能有一个模块在执行。
比如，下面这个无限循环的脚本：
function freeze() {
while(true) {
console.log('freeze');
}
}
freeze();
当这个脚本执行在一个单进程的页面的时候，由于其是无限循环的，所以会一直执行，从而导致其他模块没有机会执行代码。又因为所有页面都运行在这个线程中，所以其他页面也无法执行任务，从而导致整个浏览器失去相应，变卡顿。
问题3：不安全
由于是单进程，同时浏览器需要系统资源的支持，比如读写cookie等，所以我们无法使用沙箱技术来进行隔离，那么如果是恶意插件和js代码的话，会引发安全问题。
插件可以使用C/C++等语言来书写，通过插件可以获取到系统的任意资源，也就意味着该插件可以完全操控电脑。如果是一个恶意插件，那么它就可以窥探隐私，释放病毒等，从而引发安全性问题。
以上这些就是当时浏览器的特点，不稳定，不流畅，而且不安全。这是一段不堪回首的过去，也许你没有经历过，不过你可以想象一下这样的场景：当你正在用浏览器打开多个页面时，突然某个页面崩溃了或者失去响应，随之而来的是整个浏览器的崩溃或者无响应，然后你发现你给老板写的邮件页面也随之消失了，这时你的心情会不会和页面一样崩溃呢？
多进程-早期时代
这是2008年chrome发布时的进程架构。
从图中，我们可以发现，chrome将渲染模块和插件模块单独封装到了进程中，进程之间通过IPC进行通信。
我们来一一分析一下，它是如何解决单进程浏览器的三大问题的。
-
不稳定问题
插件、渲染模块被单独封装到了进程中，那么当一个插件或者一个tab页面奔溃的时候，不会影响到其他插件模块、渲染模块，也不会将这个浏览器搞到奔溃，从而解决了不稳定的问题
-
不流畅问题
同理，由于插件、渲染模块在主进程中的剥离，那么当某一个插件、页面发生阻塞的时候，不会影响到浏览器，也不会影响到其他的插件和页面
-
不安全问题
采用多进程后，我们可以使用沙箱技术对插件进程和渲染进程进行隔离，这样即使渲染进程或者插件进程执行了恶意程序，其也无法获得系统权限。
多进程-现状
随着chrome的发展，架构又有了新的变化。
chrome进一步的将主进程中一些服务进行了剥离，比如网络、GPU、AUDIO等。
这里简单的对这几个进程进行一下介绍
-
浏览器主进程
- 负责界面展示，与用户交互。如前进、后退、书签等
- 负责各个页面的管理，协调各个进程
- 。。。
-
渲染进程
负责将HTML,CSS,JS转换为网页。
排版引擎blink，js引擎V8都是运行在该线程中。
不过凡事都有两面性，虽然多进程提升了浏览器的稳定性、安全性、流畅性，但是同样也带来了一些问题：
更高的资源占用
更复杂的体系架构
浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了
对于这两个问题，chrome团队已经着手进行解决了，那就是面向服务架构
未来面向服务的架构
chrome整体架构采用现代操作系统所采用的面向服务的架构方向发展，将原来的各种模块，抽取、重构成独立的服务，每个服务都可以在独立的进程中运行，每个服务都会提供访问接口，通过IPC来通信，从而构建高内聚，低耦合，易于维护和扩展的系统。
chrome最终要把UI，数据库，文件，设备，网络等模块重构为基础服务，类似于操作系统的底层服务。
目前chrome正处于老的架构向服务化架构过度阶段，这将是一个漫长的过程。
chrome要做的事情，类似于操作系统正在做的事情，我们甚至可以认为chrome是一个便携式操作系统
chrome还提供了弹性方案，当运行于资源受限的设备上的时候，会自动将服务整合到一个进程中，从而减轻设备的压力。
总结
本文主要从chrome的角度对浏览器的架构进行了分析。
最初的浏览器是单进程的，他们不稳定，不流畅，不安全，之后出现了chrome,创造性的引入了多进程架构。随着chrome应用到越来越多的场景，功能也越来越复杂，原有的架构已经不能满足于场景的快速变化，chrome团队采用了面向服务架构（SOA）进行逐步重构，目前仍然在进行中。
