js异步问题怎么解决

JavaScript024

js异步问题怎么解决,第1张

异步加载又叫非阻塞加载,浏览器在下载执行js的同时,还会继续进行后续页面的处理。主要有三种方式。

方法一:也叫Script DOM Element

(function(){

var scriptEle = document.createElement("script")

scriptEle.type = "text/javasctipt"

scriptEle.async = true

scriptEle.src = "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js"

var x = document.getElementsByTagName("head")[0]

x.insertBefore(scriptEle, x.firstChild)

})()

<async>属性是HTML5中新增的异步支持。此方法被称为Script DOM Element 方法。Google Analytics 和 Google+ Badge 都使用了这种异步加载代码

(function(){

var ga = document.createElement('script')

ga.type = 'text/javascript'

ga.async = true

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'

var s = document.getElementsByTagName('script')[0]

s.parentNode.insertBefore(ga, s)

})()

但是这种加载方式执行完之前会阻止onload事件的触发,而现在很多页面的代码都在onload时还执行额外的渲染工作,所以还是会阻塞部分页面的初始化处理。

方法二:onload时的异步加载

(function(){

if(window.attachEvent){

window.attachEvent("load", asyncLoad)

}else{

window.addEventListener("load", asyncLoad)

}

var asyncLoad = function(){

var ga = document.createElement('script')

ga.type = 'text/javascript'

ga.async = true

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'

var s = document.getElementsByTagName('script')[0]

s.parentNode.insertBefore(ga, s)

}

)()

这种方法只是把插入script的方法放在一个函数里面,然后放在window的onload方法里面执行,这样就解决了阻塞onload事件触发的问题。

注:DOMContentLoaded与load的区别。前者是在document已经解析完成,页面中的dom元素可用,但是页面中的图片,视频,音频等资源未加载完,作用同jQuery中的ready事件;后者的区别在于页面所有资源全部加载完毕。

方法三:其他方法

由于JavaScript的动态性,还有很多异步加载方法: XHR Injection、 XHR Eval、 Script In Iframe、 Script defer属性、 document.write(script tag)。

XHR Injection(XHR 注入):通过XMLHttpRequest来获取javascript,然后创建一个script元素插入到DOM结构中。ajax请求成功后设置script.text为请求成功后返回的responseText。

//获取XMLHttpRequest对象,考虑兼容性。

var getXmlHttp = function(){

var obj

if (window.XMLHttpRequest)

obj = new XMLHttpRequest()

else

obj = new ActiveXObject("Microsoft.XMLHTTP")

return obj

}

//采用Http请求get方式open()方法的第三个参数表示采用异步(true)还是同步(false)处理

var xmlHttp = getXmlHttp()

xmlHttp.open("GET", "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js", true)

xmlHttp.send()

xmlHttp.onreadystatechange = function(){

if (xmlHttp.readyState == 4 &&xmlHttp.status == 200){

var script = document.createElement("script")

script.text = xmlHttp.responseText

document.getElementsByTagName("head")[0].appendChild(script)

}

}

XHR Eval:与XHR Injection对responseText的执行方式不同,直接把responseText放在eval()函数里面执行。

//获取XMLHttpRequest对象,考虑兼容性。

var getXmlHttp = function(){

var obj

if (window.XMLHttpRequest)

obj = new XMLHttpRequest()

else

obj = new ActiveXObject("Microsoft.XMLHTTP")

return obj

}

//采用Http请求get方式open()方法的第三个参数表示采用异步(true)还是同步(false)处理

var xmlHttp = getXmlHttp()

xmlHttp.open("GET", "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js", true)

xmlHttp.send()

xmlHttp.onreadystatechange = function(){

if (xmlHttp.readyState == 4 &&xmlHttp.status == 200){

eval(xmlHttp.responseText)

//alert($)//可以弹出$,表明JS已经加载进来。click事件放在其它出会出问题,应该是还没加载进来

$("#btn1").click(function(){

alert($(this).text())

})

}

}

Script In Irame:在父窗口插入一个iframe元素,然后再iframe中执行加载JS的操作。

var insertJS = function(){alert(2)}

var iframe = document.createElement("iframe")

document.body.appendChild(iframe)

var doc = iframe.contentWindow.document//获取iframe中的window要用contentWindow属性。

doc.open()

doc.write("<script>var insertJS = function(){}<\/script><body onload='insertJS()'></body>")

doc.close()

GMail Mobile:业内JS内容被注释,所以不会执行,在需要的时候,获取script中的text内容去掉注释,调用eval()执行。

<script type="text/javascript">

/*

var ...

*/

</script>

HTML5新属性:async和defer属性

defer属性:IE4.0就出现。defer属声明脚本中将不会有document.write和dom修改。浏览器会并行下载其他有defer属性的script。而不会阻塞页面后续处理。注:所有的defer脚本必须保证按顺序执行的。

<script type="text/javascript" defer></script>

async属性:HTML5新属性。脚本将在下载后尽快执行,作用同defer,但是不能保证脚本按顺序执行。他们将在onload事件之前完成。

<script type="text/javascript" defer></script>

Firefox 3.6、Opera 10.5、IE 9和最新的Chrome和Safari都支持async属性。可以同时使用async和defer,这样IE 4之后的所有IE都支持异步加载。

没有async属性,script将立即获取(下载)并执行,期间阻塞了浏览器的后续处理。如果有async属性,那么script将被异步下载并执行,同时浏览器继续后续的处理。

总结: 对于支持HTML5的浏览器,实现JS的异步加载只需要在script元素中加上async属性,为了兼容老版本的IE还需加上defer属性;对于不支持HTML5的浏览器(IE可以用defer实现),可以采用以上几种方法实现。原理基本上都是向DOM中写入script或者通过eval函数执行JS代码,你可以把它放在匿名函数中执行,也可以在onload中执行,也可以通过XHR注入实现,也可以创建一个iframe元素,然后在iframe中执行插入JS代码。

javascript语言是单线程机制。所谓单线程就是按次序执行,执行完一个任务再执行下一个。

对于浏览器来说,也就是无法在渲染页面的同时执行代码。

单线程机制的优点在于实现起来较为简单,运行环境相对简单。缺点在于,如果中间有任务需要响应时间过长,经常会导致

页面加载错误或者浏览器无响应的状况。这就是所谓的“同步模式”,程序执行顺序与任务排列顺序一致。对于浏览器来说,

同步模式效率较低,耗时长的任务都应该使用异步模式;而在服务器端,异步模式则是唯一的模式,如果采用同步模式个人认为

服务器很快就会出现12306在高峰期的表现。。。。

异步模式的四种方式:

1.回调函数callback

所谓回调函数,就是将函数作为参数传到需要回调的函数内部再执行。

典型的例子就是发送ajax请求。例如:

$.ajax({

async: false,

cache: false,

dataType: 'json',

url: "url",

success: function(data) {

console.log('success')

},

error: function(data) {

console.log('error')

}

})

当发送ajax请求后,等待回应的过程不会堵塞程序运行,耗时的操作相当于延后执行。

回调函数的优点在于简单,容易理解,但是可读性较差,耦合度较高,不易于维护。

2.事件驱动

javascript可以称之为是基于对象的语言,而基于对象的基本特征就是事件驱动(Event-Driven)。

事件驱动,指的是由鼠标和热键的动作引发的一连串的程序操作。

例如,为页面上的某个

$('#btn').onclick(function(){

console.log('click button')

})

绑定事件相当于在元素上进行监听,是否执行注册的事件代码取决于事件是否发生。

优点在于容易理解,一个元素上可以绑定多个事件,有利于实现模块化;但是缺点在于称为事件驱动的模型后,流程不清晰。

3.发布/订阅

发布订阅模式(publish-subscribe pattern)又称为观察者模式(Observer pattern)。

该模式中,有两类对象:观察者和目标对象。目标对象中存在着一份观察者的列表,当目标对象

的状态发生改变时,主动通知观察者,从而建立一种发布/订阅的关系。

jquery有相关的插件,在这不是重点不细说了。。。。回头写个实现贴上来

4.promise模式

promise对象是CommonJS工作组提供的一种规范,用于异步编程的统一接口。

promise对象通常实现一种then的方法,用来在注册状态发生改变时作为对应的回调函数。

promise模式在任何时刻都处于以下三种状态之一:未完成(unfulfilled)、已完成(resolved)和拒绝(rejected)。以CommonJS

Promise/A

标准为例,promise对象上的then方法负责添加针对已完成和拒绝状态下的处理函数。then方法会返回另一个promise对象,以便于形成promise管道,这种返回promise对象的方式能够支持开发人员把异步操作串联起来,如then(resolvedHandler,

rejectedHandler)。resolvedHandler

回调函数在promise对象进入完成状态时会触发,并传递结果;rejectedHandler函数会在拒绝状态下调用。

Jquery在1.5的版本中引入了一个新的概念叫Deferred,就是CommonJS promise A标准的一种衍生。可以在jQuery中创建

$.Deferref的对象。同时也对发送ajax请求以及数据类型有了新的修改,参考JQuery API。

除了以上四种,javascript中还可以利用各种函数模拟异步方式,更有诡异的诸如用同步调用异步的case

只能用team里同事形容java和javascript的一句话作为结尾:

“写java像在高速路上开车,写javascript像在草原上开车”-------------以此来形容javascript这种无类型的语言有多自由

but,如果草原上都是坑。

首先了解一下URL的组成:

从上面的URL可以看出,一个完整的URL包括以下几部分:

1、协议部分:该URL的协议部分为“http:”,这代表网页使用的是HTTP协议。在Internet中可以使用多种协议,如HTTP,FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

2、域名部分:该URL的域名部分为“www.baidu.com”。一个URL中,也可以使用IP地址作为域名使用

3、端口部分:跟在域名后面的是端口,域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分,如果省略端口部分,将采用默认端口80

4、虚拟目录部分:从域名后的第一个“/”开始到最后一个“/”为止,是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5、文件名部分:从域名后的最后一个“/”开始到“?”为止,是文件名部分,如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止,是文件部分,如果没有“?”和“#”,那么从域名后的最后一个“/”开始到结束,都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分,如果省略该部分,则使用默认的文件名

6、锚部分:从“#”开始到最后,都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7、参数部分:从“?”开始到“#”为止之间的部分为参数部分,又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数,参数与参数之间用“&”作为分隔符。

很多大公司面试喜欢问这样一道面试题, 输入URL到看见页面发生了什么? ,今天我们来总结一下。 简单来说,共有以下几个过程

下面我们来看看具体的细节

输入 www.google.com 网址后,首先在本地的域名服务器中查找,没找到去根域名服务器查找,没有再去 com 顶级域名服务器查找,,如此的类推下去,直到找到IP地址,然后把它记录在本地,供下次使用。大致过程就是 .->.com -> google.com.-> www.google.com. 。 (你可能觉得我多写 .,并木有,这个.对应的就是根域名服务器,默认情况下所有的网址的最后一位都是.,既然是默认情况下,为了方便用户,通常都会省略,浏览器在请求DNS的时候会自动加上)

既然已经懂得了解析的具体过程,我们可以看到上述一共经过了N个过程,每个过程有一定的消耗和时间的等待,因此我们得想办法解决一下这个问题!

DNS存在着多级缓存,从离浏览器的距离排序的话,有以下几种: 浏览器缓存,系统缓存,路由器缓存,IPS服务器缓存,根域名服务器缓存,顶级域名服务器缓存,主域名服务器缓存。

在你的chrome浏览器中输入:chrome://dns/,你可以看到chrome浏览器的DNS缓存。

系统缓存主要存在/etc/hosts(Linux系统)中

检查浏览器是否有缓存

通过 Cache-Control 和 Expires 来检查是否命中强缓存,命中则直接取本地磁盘的html(状态码为200 from disk(or memory) cache,内存or磁盘);

如果没有命中强缓存,则会向服务器发起请求(先进行下一步的TCP连接),服务器通过 Etag 和 Last-Modify 来与服务器确认返回的响应是否被更改(协商缓存),若无更改则返回状态码(304 Not Modified),浏览器取本地缓存;

若强缓存和协商缓存都没有命中则返回请求结果。

不知道你们有没有注意这样一件事,你访问http://baidu.com的时候,每次响应的并非是同一个服务器(IP地址不同),一般大公司都有成百上千台服务器来支撑访问,假设只有一个服务器,那它的性能和存储量要多大才能支撑这样大量的访问呢?DNS可以返回一个合适的机器的IP给用户,例如可以根据每台机器的负载量,该机器离用户地理位置的距离等等,这种过程就是DNS负载均衡

TCP 协议通过三次握手建立连接。

翻译成大白话就是:

为什么是3次? :避免 历史 连接,确认客户端发来的请求是这次通信的人。

为什么不是4次? :3次够了第四次浪费

建立连接的过程是利用客户服务器模式,假设主机A为客户端,主机B为服务器端。

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B,因而产生错误。失效的连接请求报文段是指:主机A发出的连接请求没有收到主机B的确认,于是经过一段时间后,主机A又重新向主机B发送连接请求,且建立成功,顺序完成数据传输。考虑这样一种特殊情况,主机A第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到主机B,主机B以为是主机A又发起的新连接,于是主机B同意连接,并向主机A发回确认,但是此时主机A根本不会理会,主机B就一直在等待主机A发送数据,导致主机B的资源浪费。

采用两次握手不行,原因就是上面说的失效的连接请求的特殊情况。而在三次握手中, client和server都有一个发syn和收ack的过程, 双方都是发后能收, 表明通信则准备工作OK.

为什么不是四次握手呢? 大家应该知道通信中著名的蓝军红军约定, 这个例子说明, 通信不可能100%可靠, 而上面的三次握手已经做好了通信的准备工作, 再增加握手, 并不能显著提高可靠性, 而且也没有必要。

第一次握手

客户端发送syn包(Seq=x)到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:

服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(Seq=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:

客户端收到服务器的SYN ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。

要先申请CA证书,并安装在服务器上(一个文件,配置nginx支持监听443端口开启ssl并设置证书路径)

浏览器发送请求;

网站从浏览器发过来的加密规则中选一组自身也支持的加密算法和hash算法,并向浏览器发送带有公钥的证书,当然证书还包含了很多信息,如网站地址、证书的颁发机构、过期时间等。

浏览器解析证书。

验证证书的合法性。如颁发机构是否合法、证书中的网站地址是否与访问的地址一致,若不合法,则浏览器提示证书不受信任,若合法,浏览器会显示一个小锁头。

若合法,或用户接受了不合法的证书,浏览器会生成一串随机数的密码(即密钥),并用证书中提供的公钥加密。

使用约定好的hash计算握手消息,并使用生成的随机数(即密钥)对消息进行加密,最后将之前生成的所有消息一并发送给网站服务器。

网站服务器解析消息。用已有的私钥将密钥解密出来,然后用密钥解密发过来的握手消息,并验证是否跟浏览器传过来的一致。然后再用密钥加密一段握手消息,发送给浏览器。

浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。

发送HTTP请求

首先科补一个小知识,HTTP的端口为80/8080,而HTTPS的端口为443

发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口 请求报文由 请求行 请求抱头 请求正文 组成。

请求行

请求行的格式为 Method Request-URL HTTP-Version CRLF eg: GET index.html HTTP/1.1常用的方法有:GET ,POST ,PUT ,DELETE ,OPTIONS ,HEAD 。

常见的请求方法区别

这里主要展示 POST 和 GET 的区别

常见的区别

注意一点你也可以在GET里面藏body,POST里面带参数

重点区别

GET 会产生一个 TCP 数据包,而 POST 会产生两个 TCP 数据包。

详细的说就是:

注意一点,并不是所有的浏览器都会发送两次数据包,Firefox就发送一次

请求报头

请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。

从图中可以看出,请求报头中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息,Accept-Encoding与Accept类似,它用于指定接受的编码方式。Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接,这样可以使下次HTTP请求使用相同的TCP通道,节省TCP连接建立的时间。

请求正文

当使用POST, PUT等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息,例如: 现在的Web应用通常采用Rest架构,请求的数据格式一般为json。这时就需要设置 Content-Type: application/json 。

更重要的事情-HTTP缓存

HTTP属于客户端缓存,我们常认为浏览器有一个缓存数据库,用来保存一些静态文件,下面我们分为以下几个方面来简单介绍HTTP缓存

缓存的规则

缓存规则分为 强制缓存 协商缓存

强制缓存

当缓存数据库中有客户端需要的数据,客户端直接将数据从其中拿出来使用(如果数据未失效),当缓存服务器没有需要的数据时,客户端才会向服务端请求。

又称对比缓存。客户端会先从缓存数据库拿到一个缓存的标识,然后向服务端验证标识是否失效,如果没有失效服务端会返回304,这样客户端可以直接去缓存数据库拿出数据,如果失效,服务端会返回新的数据

强制缓存

对于强制缓存,服务器响应的header中会用两个字段来表明——Expires和Cache-Control。

Expires

Exprires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间,则直接使用缓存数据。但由于服务端时间和客户端时间可能有误差,这也将导致缓存命中的误差,另一方面,Expires是HTTP1.0的产物,故现在大多数使用Cache-Control替代。

Cache-Control

Cache-Control有很多属性,不同的属性代表的意义也不同。

协商缓存

协商缓存需要进行对比判断是否可以使用缓存。浏览器第一次请求数据时,服务器会将缓存标识与数据一起响应给客户端,客户端将它们备份至缓存中。再次请求时,客户端会将缓存中的标识发送给服务器,服务器根据此标识判断。若未失效,返回304状态码,浏览器拿到此状态码就可以直接使用缓存数据了。

对于协商缓存来说,缓存标识我们需要着重理解一下,下面我们将着重介绍它的两种缓存方案。

Last-Modified

Last-Modified:服务器在响应请求时,会告诉浏览器资源的最后修改时间。

从字面上看,就是说:从某个时间节点算起,是否文件被修改了

这两个的区别是一个是修改了才下载一个是没修改才下载。

Last-Modified 说好却也不是特别好,因为如果在服务器上,一个资源被修改了,但其实际内容根本没发生改变,会因为Last-Modified时间匹配不上而返回了整个实体给客户端(即使客户端缓存里有个一模一样的资源)。为了解决这个问题,HTTP1.1推出了Etag。

Etag

Etag:服务器响应请求时,通过此字段告诉浏览器当前资源在服务器生成的唯一标识(生成规则由服务器决定)

但是实际应用中由于Etag的计算是使用算法来得出的,而算法会占用服务端计算的资源,所有服务端的资源都是宝贵的,所以就很少使用Etag了。

缓存的优点

不同刷新的请求执行过程

浏览器地址栏中写入URL,回车

F5

Ctrl+F5

服务器处理请求并返回HTTP报文

它会对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成HTTP Request对象,供上层使用。这一部分工作一般是由Web服务器去进行,我使用过的Web服务器有Tomcat, Nginx和Apache等等 HTTP报文也分成三份, 状态码 响应报头 响应报文

状态码

状态码是由3位数组成,第一个数字定义了响应的类别,且有五种可能取值:

平时遇到比较常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500

常见状态码区别

200 成功

请求成功,通常服务器提供了需要的资源。

204 无内容

服务器成功处理了请求,但没有返回任何内容。

301 永久移动

请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。

302 临时移动

服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。

304 未修改

自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。

400 错误请求

服务器不理解请求的语法。

401 未授权

请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。

403 禁止

服务器拒绝请求。

404 未找到

服务器找不到请求的网页。

422 无法处理

请求格式正确,但是由于含有语义错误,无法响应

500 服务器内部错误

服务器遇到错误,无法完成请求。

响应报头

常见的响应报头字段有: Server, Connection...。

响应报文

你从服务器请求的HTML,CSS,JS文件就放在这里面

就是 Webkit 解析渲染页面的过程。

这个过程涉及两个比较重要的概念 回流 重绘 ,DOM结点都是以盒模型形式存在,需要浏览器去计算位置和宽度等,这个过程就是回流。等到页面的宽高,大小,颜色等属性确定下来后,浏览器开始绘制内容,这个过程叫做重绘。浏览器刚打开页面一定要经过这两个过程的,但是这个过程非常非常非常消耗性能,所以我们应该尽量减少页面的回流和重绘

这个过程中可能会有dom操作、ajax发起的http网络请求等。

web-socket、ajax等,这个过程通常是为了获取数据

setTimeout、setInterval、Promise等宏任务、微任务队列

当Render Tree中部分或全部元素的尺寸、结构、或某些属性发生改变时,浏览器重新渲染部分或全部文档的过程称为回流。

会导致回流的操作:

一些常用且会导致回流的属性和方法:

当页面中元素样式的改变并不影响它在文档流中的位置时(例如:color、background-color、visibility等),浏览器会将新样式赋予给元素并重新绘制它,这个过程称为重绘。

JS的解析是由浏览器的JS引擎完成的。由于JavaScript是单线程运行,也就是说一个时间只能干一件事,干这件事情时其他事情都有排队,但是有些人物比较耗时(例如IO操作),所以将任务分为 同步任务 异步任务 ,所有的同步任务放在主线程上执行,形成执行栈,而异步任务等待,当执行栈被清空时才去看看异步任务有没有东西要搞,有再提取到主线程执行,这样往复循环(冤冤相报何时了,阿弥陀佛),就形成了Event Loop事件循环,下面来看看大人物

先看一段代码

结果我想大家都应该知道。主要来介绍JavaScript的解析,至于Promise等下一节再说

JavaScript是一门单线程语言,尽管H5中提出了 Web-Worker ,能够模拟实现多线程,但本质上还是单线程,说它是多线程就是扯淡。

既然是单线程,每个事件的执行就要有顺序,比如你去银行取钱,前面的人在进行,后面的就得等待,要是前面的人弄个一两个小时,估计后面的人都疯了,因此,浏览器的JS引擎处理JavaScript时分为 同步任务 异步任务

这张图我们可以清楚看到

js引擎存在monitoring process进程,会持续不断的检查主线程执行栈是否为空,一旦为空,就会去Event Queue那里检查是否有等待被调用的函数。 估计看完这些你对事件循环有一定的了解,但是事实上我们看对的没这么简单,通常我们会看到Promise,setTimeout,process.nextTick(),这个时候你和我就懵逼。

不同任务会进入不同的任务队列来执行。 JS引擎开始工作后,先在宏任务中开始第一次循环( script里面先执行,不过我喜欢把它拎出来,直接称其进入执行栈 ),当主线程执行栈全部任务被清空后去微任务看看,如果有等待执行的任务,执行全部的微任务(其实将其回调函数推入执行栈来执行),再去宏任务找最先进入队列的任务执行,执行这个任务后再去主线程执行任务(例如执行```console.log("hello world")这种任务),执行栈被清空后再去微任务,这样往复循环(冤冤相报何时了)

下面来看一段代码

我们看看它的执行情况

具体的执行过程大致就是这样。