JS的引擎深入分析-转载

Posted 诛仙物语

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JS的引擎深入分析-转载相关的知识,希望对你有一定的参考价值。

 

浏览器的组成

浏览器的核心是两部分:渲染引擎和javascript解释器(又称JavaScript引擎)。

(1)渲染引擎

渲染引擎的主要作用是,将网页从代码“渲染”为用户视觉上可以感知的平面文档。不同的浏览器有不同的渲染引擎。

  • Firefox:Gecko引擎
  • Safari:WebKit引擎
  • Chrome:Blink引擎
  • IE: Trident引擎
  • Edge: Edgehtml引擎

渲染引擎处理网页,通常分成四个阶段。

  1. 解析代码:HTML代码解析为DOM,CSS代码解析为CSSOM(CSS Object Model)
  2. 对象合成:将DOM和CSSOM合成一棵渲染树(render tree)
  3. 布局:计算出渲染树的布局(layout)
  4. 绘制:将渲染树绘制到屏幕

以上四步并非严格按顺序执行,往往第一步还没完成,第二步和第三步就已经开始了。所以,会看到这种情况:网页的HTML代码还没下载完,但浏览器已经显示出内容了。

(2)JavaScript引擎

JavaScript引擎的主要作用是,读取网页中的JavaScript代码,对其处理后运行。

本节主要介绍JavaScript引擎的工作方式。

JavaScript代码嵌入网页的方法

JavaScript代码只有嵌入网页,才能运行。网页中嵌入JavaScript代码有多种方法。

直接添加代码块

通过<script>标签,可以直接将JavaScript代码嵌入网页。

<script>console.log(‘Hello World‘);
</script>

<script>标签有一个type属性,用来指定脚本类型。不过,如果嵌入的是JavaScript脚本,type属性可以省略。

对JavaScript脚本来说,type属性可以设为两种值。

  • text/javascript:这是默认值,也是历史上一贯设定的值。如果你省略type属性,默认就是这个值。对于老式浏览器,设为这个值比较好。
  • application/javascript:对于较新的浏览器,建议设为这个值。

加载外部脚本

script标签也可以指定加载外部的脚本文件。

<script src="example.js"></script>

如果脚本文件使用了非英语字符,还应该注明编码。

<script charset="utf-8"src="example.js"></script>

加载外部脚本和直接添加代码块,这两种方法不能混用。下面代码的console.log语句直接被忽略。

<script charset="utf-8"src="example.js">console.log(‘Hello World!‘);
</script>

为了防止攻击者篡改外部脚本,script标签允许设置一个integrity属性,写入该外部脚本的Hash签名,用来验证脚本的一致性。

<script src="/assets/application.js"integrity="sha256-TvVUHzSfftWg1rcfL6TIJ0XKEGrgLyEq6lEpcmrG9qs="></script>

上面代码中,script标签有一个integrity属性,指定了外部脚本/assets/application.js的SHA265签名。一旦有人改了这个脚本,导致SHA265签名不匹配,浏览器就会拒绝加载。

除了JavaScript脚本,外部的CSS样式表也可以设置这个属性。

行内代码

除了上面两种方法,HTML语言允许在某些元素的事件属性和a元素的href属性中,直接写入JavaScript。

<divonclick="alert(‘Hello‘)"></div><ahref="javascript:alert(‘Hello‘)"></a>

这种写法将HTML代码与JavaScript代码混写在一起,非常不利于代码管理,不建议使用。

<script>标签的工作原理

正常的网页加载流程是这样的。

  1. 浏览器一边下载HTML网页,一边开始解析
  2. 解析过程中,发现<script>标签
  3. 暂停解析,网页渲染的控制权转交给JavaScript引擎
  4. 如果<script>标签引用了外部脚本,就下载该脚本,否则就直接执行
  5. 执行完毕,控制权交还渲染引擎,恢复往下解析HTML网页

也就是说,加载外部脚本时,浏览器会暂停页面渲染,等待脚本下载并执行完成后,再继续渲染。原因是JavaScript可以修改DOM(比如使用document.write方法),所以必须把控制权让给它,否则会导致复杂的线程竞赛的问题。

如果外部脚本加载时间很长(比如一直无法完成下载),就会造成网页长时间失去响应,浏览器就会呈现“假死”状态,这被称为“阻塞效应”。

为了避免这种情况,较好的做法是将<script>标签都放在页面底部,而不是头部。这样即使遇到脚本失去响应,网页主体的渲染也已经完成了,用户至少可以看到内容,而不是面对一张空白的页面。

如果某些脚本代码非常重要,一定要放在页面头部的话,最好直接将代码嵌入页面,而不是连接外部脚本文件,这样能缩短加载时间。

将脚本文件都放在网页尾部加载,还有一个好处。在DOM结构生成之前就调用DOM,JavaScript会报错,如果脚本都在网页尾部加载,就不存在这个问题,因为这时DOM肯定已经生成了。

<head><script>console.log(document.body.innerHTML);
  </script></head><body></body>

上面代码执行时会报错,因为此时document.body元素还未生成。

一种解决方法是设定DOMContentLoaded事件的回调函数。

<head><script>
    document.addEventListener(
      ‘DOMContentLoaded‘,
      function (event) {
        console.log(document.body.innerHTML);
      }
    );
  </script></head>

另一种解决方法是,使用<script>标签的onload属性。当<script>标签指定的外部脚本文件下载和解析完成,会触发一个load事件,可以把所需执行的代码,放在这个事件的回调函数里面。

<script src="jquery.min.js"onload="console.log(document.body.innerHTML)"></script>

但是,如果将脚本放在页面底部,就可以完全按照正常的方式写,上面两种方式都不需要。

<body><!-- 其他代码  --><script>console.log(document.body.innerHTML);
  </script></body>

如果有多个script标签,比如下面这样。

<script src="a.js"></script><script src="b.js"></script>

浏览器会同时并行下载a.jsb.js,但是,执行时会保证先执行a.js,然后再执行b.js,即使后者先下载完成,也是如此。也就是说,脚本的执行顺序由它们在页面中的出现顺序决定,这是为了保证脚本之间的依赖关系不受到破坏。

当然,加载这两个脚本都会产生“阻塞效应”,必须等到它们都加载完成,浏览器才会继续页面渲染。

Gecko和Webkit引擎在网页被阻塞后,会生成第二个线程解析文档,下载外部资源,但是不会修改DOM,网页还是处于阻塞状态。

解析和执行CSS,也会产生阻塞。Firefox会等到脚本前面的所有样式表,都下载并解析完,再执行脚本;Webkit则是一旦发现脚本引用了样式,就会暂停执行脚本执行,等到样式表下载并解析完,再恢复执行。

此外,对于来自同一个域名的资源,比如脚本文件、样式表文件、图片文件等,浏览器一般最多同时下载六个(IE11允许同时下载13个)。如果是来自不同域名的资源,就没有这个限制。所以,通常把静态文件放在不同的域名之下,以加快下载速度。

defer属性

为了解决脚本文件下载阻塞网页渲染的问题,一个方法是加入defer属性。

<script src="1.js"defer></script><script src="2.js"defer></script>

defer属性的作用是,告诉浏览器,等到DOM加载完成后,再执行指定脚本。

  1. 浏览器开始解析HTML网页
  2. 解析过程中,发现带有defer属性的script标签
  3. 浏览器继续往下解析HTML网页,同时并行下载script标签中的外部脚本
  4. 浏览器完成解析HTML网页,此时再执行下载的脚本

有了defer属性,浏览器下载脚本文件的时候,不会阻塞页面渲染。下载的脚本文件在DOMContentLoaded事件触发前执行(即刚刚读取完</html>标签),而且可以保证执行顺序就是它们在页面上出现的顺序。

对于内置而不是连接外部脚本的script标签,以及动态生成的script标签,defer属性不起作用。

async属性

解决“阻塞效应”的另一个方法是加入async属性。

<script src="1.js"async></script><script src="2.js"async></script>

async属性的作用是,使用另一个进程下载脚本,下载时不会阻塞渲染。

  1. 浏览器开始解析HTML网页
  2. 解析过程中,发现带有async属性的script标签
  3. 浏览器继续往下解析HTML网页,同时并行下载script标签中的外部脚本
  4. 脚本下载完成,浏览器暂停解析HTML网页,开始执行下载的脚本
  5. 脚本执行完毕,浏览器恢复解析HTML网页

async属性可以保证脚本下载的同时,浏览器继续渲染。需要注意的是,一旦采用这个属性,就无法保证脚本的执行顺序。哪个脚本先下载结束,就先执行那个脚本。另外,使用async属性的脚本文件中,不应该使用document.write方法。

defer属性和async属性到底应该使用哪一个?

一般来说,如果脚本之间没有依赖关系,就使用async属性,如果脚本之间有依赖关系,就使用defer属性。如果同时使用asyncdefer属性,后者不起作用,浏览器行为由async属性决定。

重流和重绘

渲染树转换为网页布局,称为“布局流”(flow);布局显示到页面的这个过程,称为“绘制”(paint)。它们都具有阻塞效应,并且会耗费很多时间和计算资源。

页面生成以后,脚本操作和样式表操作,都会触发重流(reflow)和重绘(repaint)。用户的互动,也会触发,比如设置了鼠标悬停(a:hover)效果、页面滚动、在输入框中输入文本、改变窗口大小等等。

重流和重绘并不一定一起发生,重流必然导致重绘,重绘不一定需要重流。比如改变元素颜色,只会导致重绘,而不会导致重流;改变元素的布局,则会导致重绘和重流。

大多数情况下,浏览器会智能判断,将重流和重绘只限制到相关的子树上面,最小化所耗费的代价,而不会全局重新生成网页。

作为开发者,应该尽量设法降低重绘的次数和成本。比如,尽量不要变动高层的DOM元素,而以底层DOM元素的变动代替;再比如,重绘table布局和flex布局,开销都会比较大。

varfoo= document.getElementById(‘foobar‘);

foo.style.color=‘blue‘;
foo.style.marginTop=‘30px‘;

上面的代码只会导致一次重绘,因为浏览器会累积DOM变动,然后一次性执行。

下面是一些优化技巧。

  • 读取DOM或者写入DOM,尽量写在一起,不要混杂
  • 缓存DOM信息
  • 不要一项一项地改变样式,而是使用CSS class一次性改变样式
  • 使用document fragment操作DOM
  • 动画时使用absolute定位或fixed定位,这样可以减少对其他元素的影响
  • 只在必要时才显示元素
  • 使用window.requestAnimationFrame(),因为它可以把代码推迟到下一次重流时执行,而不是立即要求页面重流
  • 使用虚拟DOM(virtual DOM)库

下面是一个window.requestAnimationFrame()对比效果的例子。

// 重绘代价高functiondoubleHeight(element) {
  varcurrentHeight=element.clientHeight;
  element.style.height= (currentHeight*2) +‘px‘;
}

all_my_elements.forEach(doubleHeight);

// 重绘代价低functiondoubleHeight(element) {
  varcurrentHeight=element.clientHeight;

  window.requestAnimationFrame(function () {
    element.style.height= (currentHeight*2) +‘px‘;
  });
}

all_my_elements.forEach(doubleHeight);

脚本的动态嵌入

除了用静态的script标签,还可以动态嵌入script标签。

[‘1.js‘, ‘2.js‘].forEach(function(src) {
  varscript= document.createElement(‘script‘);
  script.src=src;
  document.head.appendChild(script);
});

这种方法的好处是,动态生成的script标签不会阻塞页面渲染,也就不会造成浏览器假死。但是问题在于,这种方法无法保证脚本的执行顺序,哪个脚本文件先下载完成,就先执行哪个。

如果想避免这个问题,可以设置async属性为false

[‘1.js‘, ‘2.js‘].forEach(function(src) {
  varscript= document.createElement(‘script‘);
  script.src=src;
  script.async=false;
  document.head.appendChild(script);
});

上面的代码依然不会阻塞页面渲染,而且可以保证2.js1.js后面执行。不过需要注意的是,在这段代码后面加载的脚本文件,会因此都等待2.js执行完成后再执行。

我们可以把上面的写法,封装成一个函数。

(function() {
  varscripts= document.getElementsByTagName(‘script‘)[0];
  functionload(url) {
    varscript= document.createElement(‘script‘);
    script.async=true;
    script.src=url;
    scripts.parentNode.insertBefore(script, scripts);
  }
  load(‘//apis.google.com/js/plusone.js‘);
  load(‘//platform.twitter.com/widgets.js‘);
  load(‘//s.thirdpartywidget.com/widget.js‘);
}());

上面代码中,async属性设为true,是因为加载的脚本没有互相依赖关系。而且,这样就不会造成堵塞。

此外,动态嵌入还有一个地方需要注意。动态嵌入必须等待CSS文件加载完成后,才会去下载外部脚本文件。静态加载就不存在这个问题,script标签指定的外部脚本文件,都是与CSS文件同时并发下载的。

加载使用的协议

如果不指定协议,浏览器默认采用HTTP协议下载。

<script src="example.js"></script>

上面的example.js默认就是采用HTTP协议下载,如果要采用HTTPS协议下载,必需写明(假定服务器支持)。

<script src="https://example.js"></script>

但是有时我们会希望,根据页面本身的协议来决定加载协议,这时可以采用下面的写法。

<script src="//example.js"></script>

JavaScript虚拟机

JavaScript是一种解释型语言,也就是说,它不需要编译,可以由解释器实时运行。这样的好处是运行和修改都比较方便,刷新页面就可以重新解释;缺点是每次运行都要调用解释器,系统开销较大,运行速度慢于编译型语言。为了提高运行速度,目前的浏览器都将JavaScript进行一定程度的编译,生成类似字节码(bytecode)的中间代码,以提高运行速度。

早期,浏览器内部对JavaScript的处理过程如下:

  1. 读取代码,进行词法分析(Lexical analysis),将代码分解成词元(token)。
  2. 对词元进行语法分析(parsing),将代码整理成“语法树”(syntax tree)。
  3. 使用“翻译器”(translator),将代码转为字节码(bytecode)。
  4. 使用“字节码解释器”(bytecode interpreter),将字节码转为机器码。

逐行解释将字节码转为机器码,是很低效的。为了提高运行速度,现代浏览器改为采用“即时编译”(Just In Time compiler,缩写JIT),即字节码只在运行时编译,用到哪一行就编译哪一行,并且把编译结果缓存(inline cache)。通常,一个程序被经常用到的,只是其中一小部分代码,有了缓存的编译结果,整个程序的运行速度就会显著提升。

不同的浏览器有不同的编译策略。有的浏览器只编译最经常用到的部分,比如循环的部分;有的浏览器索性省略了字节码的翻译步骤,直接编译成机器码,比如chrome浏览器的V8引擎。

字节码不能直接运行,而是运行在一个虚拟机(Virtual Machine)之上,一般也把虚拟机称为JavaScript引擎。因为JavaScript运行时未必有字节码,所以JavaScript虚拟机并不完全基于字节码,而是部分基于源码,即只要有可能,就通过JIT(just in time)编译器直接把源码编译成机器码运行,省略字节码步骤。这一点与其他采用虚拟机(比如Java)的语言不尽相同。这样做的目的,是为了尽可能地优化代码、提高性能。下面是目前最常见的一些JavaScript虚拟机:

单线程模型

含义

首先,明确一个观念:JavaScript只在一个线程上运行,不代表JavaScript引擎只有一个线程。事实上,JavaScript引擎有多个线程,其中单个脚本只能在一个线程上运行,其他线程都是在后台配合。JavaScript脚本在一个线程里运行。这意味着,一次只能运行一个任务,其他任务都必须在后面排队等待。

JavaScript之所以采用单线程,而不是多线程,跟历史有关系。JavaScript从诞生起就是单线程,原因是不想让浏览器变得太复杂,因为多线程需要共享资源、且有可能修改彼此的运行结果,对于一种网页脚本语言来说,这就太复杂了。比如,假定JavaScript同时有两个线程,一个线程在某个DOM节点上添加内容,另一个线程删除了这个节点,这时浏览器应该以哪个线程为准?所以,为了避免复杂性,从一诞生,JavaScript就是单线程,这已经成了这门语言的核心特征,将来也不会改变。

为了利用多核CPU的计算能力,HTML5提出Web Worker标准,允许JavaScript脚本创建多个线程,但是子线程完全受主线程控制,且不得操作DOM。所以,这个新标准并没有改变JavaScript单线程的本质。

单线程模型带来了一些问题,主要是新的任务被加在队列的尾部,只有前面的所有任务运行结束,才会轮到它执行。如果有一个任务特别耗时,后面的任务都会停在那里等待,造成浏览器失去响应,又称“假死”。为了避免“假死”,当某个操作在一定时间后仍无法结束,浏览器就会跳出提示框,询问用户是否要强行停止脚本运行。

如果排队是因为计算量大,CPU忙不过来,倒也算了,但是很多时候CPU是闲着的,因为IO设备(输入输出设备)很慢(比如Ajax操作从网络读取数据),不得不等着结果出来,再往下执行。JavaScript语言的设计者意识到,这时CPU完全可以不管IO设备,挂起处于等待中的任务,先运行排在后面的任务。等到IO设备返回了结果,再回过头,把挂起的任务继续执行下去。这种机制就是JavaScript内部采用的Event Loop。

消息队列

JavaScript运行时,除了一根运行线程,系统还提供一个消息队列(message queue),里面是各种需要当前程序处理的消息。新的消息进入队列的时候,会自动排在队列的尾端。

运行线程只要发现消息队列不为空,就会取出排在第一位的那个消息,执行它对应的回调函数。等到执行完,再取出排在第二位的消息,不断循环,直到消息队列变空为止。

每条消息与一个回调函数相联系,也就是说,程序只要收到这条消息,就会执行对应的函数。另一方面,进入消息队列的消息,必须有对应的回调函数。否则这个消息就会遗失,不会进入消息队列。举例来说,鼠标点击就会产生一条消息,报告click事件发生了。如果没有回调函数,这个消息就遗失了。如果有回调函数,这个消息进入消息队列。等到程序收到这个消息,就会执行click事件的回调函数。

另一种情况是setTimeout会在指定时间向消息队列添加一条消息。如果消息队列之中,此时没有其他消息,这条消息会立即得到处理;否则,这条消息会不得不等到其他消息处理完,才会得到处理。因此,setTimeout指定的执行时间,只是一个最早可能发生的时间,并不能保证一定会在那个时间发生。

一旦当前执行栈空了,消息队列就会取出排在第一位的那条消息,传入程序。程序开始执行对应的回调函数,等到执行完,再处理下一条消息。

Event Loop

所谓Event Loop,指的是一种内部循环,用来一轮又一轮地处理消息队列之中的消息,即执行对应的回调函数。Wikipedia的定义是:“Event Loop是一个程序结构,用于等待和发送消息和事件(a programming construct that waits for and dispatches events or messages in a program)”。可以就把Event Loop理解成动态更新的消息队列本身。

下面是一些常见的JavaScript任务。

  • 执行JavaScript代码
  • 对用户的输入(包含鼠标点击、键盘输入等等)做出反应
  • 处理异步的网络请求

所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,在JavaScript执行进程上排队执行的任务,只有前一个任务执行完毕,才能执行后一个任务;异步任务指的是,不进入JavaScript执行进程、而进入“任务队列”(task queue)的任务,只有“任务队列”通知主进程,某个异步任务可以执行了,该任务(采用回调函数的形式)才会进入JavaScript进程执行。

以Ajax操作为例,它可以当作同步任务处理,也可以当作异步任务处理,由开发者决定。如果是同步任务,主线程就等着Ajax操作返回结果,再往下执行;如果是异步任务,该任务直接进入“任务队列”,JavaScript进程跳过Ajax操作,直接往下执行,等到Ajax操作有了结果,JavaScript进程再执行对应的回调函数。

也就是说,虽然JavaScript只有一根进程用来执行,但是并行的还有其他进程(比如,处理定时器的进程、处理用户输入的进程、处理网络通信的进程等等)。这些进程通过向任务队列添加任务,实现与JavaScript进程通信。

想要理解Event Loop,就要从程序的运行模式讲起。运行以后的程序叫做“进程”(process),一般情况下,一个进程一次只能执行一个任务。如果有很多任务需要执行,不外乎三种解决方法。

  1. 排队。因为一个进程一次只能执行一个任务,只好等前面的任务执行完了,再执行后面的任务。

  2. 新建进程。使用fork命令,为每个任务新建一个进程。

  3. 新建线程。因为进程太耗费资源,所以如今的程序往往允许一个进程包含多个线程,由线程去完成任务。

如果某个任务很耗时,比如涉及很多I/O(输入/输出)操作,那么线程的运行大概是下面的样子。

 

上图的绿色部分是程序的运行时间,红色部分是等待时间。可以看到,由于I/O操作很慢,所以这个线程的大部分运行时间都在空等I/O操作的返回结果。这种运行方式称为”同步模式”(synchronous I/O)。

如果采用多线程,同时运行多个任务,那很可能就是下面这样。

 

上图表明,多线程不仅占用多倍的系统资源,也闲置多倍的资源,这显然不合理。

 

上图主线程的绿色部分,还是表示运行时间,而橙色部分表示空闲时间。每当遇到I/O的时候,主线程就让Event Loop线程去通知相应的I/O程序,然后接着往后运行,所以不存在红色的等待时间。等到I/O程序完成操作,Event Loop线程再把结果返回主线程。主线程就调用事先设定的回调函数,完成整个任务。

可以看到,由于多出了橙色的空闲时间,所以主线程得以运行更多的任务,这就提高了效率。这种运行方式称为”异步模式“(asynchronous I/O)。

这正是JavaScript语言的运行方式。单线程模型虽然对JavaScript构成了很大的限制,但也因此使它具备了其他语言不具备的优势。如果部署得好,JavaScript程序是不会出现堵塞的,这就是为什么node.js平台可以用很少的资源,应付大流量访问的原因。

如果有大量的异步任务(实际情况就是这样),它们会在“消息队列”中产生大量的消息。这些消息排成队,等候进入主线程。本质上,“消息队列”就是一个“先进先出”的数据结构。比如,点击鼠标就产生一系列消息(各种事件),mousedown事件排在mouseup事件前面,mouseup事件又排在click事件的前面。

参考链接

以上是关于JS的引擎深入分析-转载的主要内容,如果未能解决你的问题,请参考以下文章

对 Node.js 事件驱动模型的深入理解

深入了解JVM——虚拟机字节码执行引擎

深入了解JVM——虚拟机字节码执行引擎

深入node.js 3 模板引擎原理 事件 文件操作 可读流的实现原理

转载深入理解PHP Opcode缓存原理

深入浅出分析MySQL常用存储引擎