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