龙空技术网

浏览器事件循环

闪念基因 412

前言:

如今小伙伴们对“historyapiajax报错”大约比较注意,我们都需要学习一些“historyapiajax报错”的相关文章。那么小编在网络上收集了一些对于“historyapiajax报错””的相关文章,希望你们能喜欢,咱们一起来学习一下吧!

浏览器运行过程中会同时面对多种任务,用户交互事件(鼠标、键盘)、网络请求、页面渲染等。而这些任务不能是无序的,必须有个先来后到,浏览器内部需要一套预定的逻辑来有序处理这些任务,因此浏览器事件循环诞生了,再次强调,是浏览器事件循环,不是javascript事件循环,js只是浏览器事件循环的参与者。

二、事件循环是什么

浏览器把任务区分成了 宏任务 和 微任务 或者叫 外部任务 和 内部任务 ,内部任务可以理解为js内部处理的任务,外部任务可以认为是浏览器处理的任务。

外部队列/宏任务队列(Task Queue)

也可以叫宏任务队列,浏览器中的外部事件源包含以下几种:

dom操作(页面渲染)用户交互(鼠标、键盘)网络请求(Ajax等)History API操作(history.back、history.go...)定时器(setTimeout)

这些外部事件源可能很多,为了方便浏览器厂商优化,HTML标准中明确指出一个事件循环有一个或多个外部队列,而每一个外部事件源都有一个对应的外部队列。不同的时间源之间可以有不同的优先级(例如在网络时间和用户交互之间,浏览器可以优先处理鼠标行为,从而让用户感觉更加流畅)。

内部队列/微任务队列(Microtask Queue)

也可以叫微任务队列,指的就是javascript语言内部的事件队列,在HTML标准中,并没有明确规定这个队列的事件源,通常认为有以下几种:

Promise的成功(.then)与失败(.catch)MutationObserverObject.observe(已废弃)

以上三种除了第一个,其他两个可以认为没有,实际上我们js中能够使用的就只有promise。

事件循环模型

先来一张事件循环处理模型的截图:

可以看出,每一个事件循环,从外部任务队列中拿出一个来执行,执行完一个外部任务后立即执行内部任务队列中所有内部任务(清空),然后浏览器执行一次渲染,然后再次循环。

一段经典代码

了解了两种队列和事件循环的执行模型,下面来一段经典代码:

// 以下代码会得到什么样的输出结果?console.log('1');setTimeout(function() {   console.log('2');   Promise.resolve().then(function() {		console.log('3');   });}, 0);Promise.resolve().then(function() {   console.log('4');}).then(function() {   console.log('5');});console.log('6');

答案是:164523

执行顺序如下:

由于执行当前js代码这个任务是一个宏任务,因此首先输出的是"1",继续执行遇到setTimeou,由于setTimeout是一个外部事件源,它内部的代码会被push到TaskQueue中等待下一次事件循环再执行,当执行到promise的 then 或 catchd的时候会将他们按顺序追加到本轮事件循环的末尾,再继续往下执行输出6,宏任务完成后清空微任务队列中的任务,继而输出4、5如果有的话,执行渲染任务后,本次事件循环结束开始执行下一个宏任务,也就是第一个setTimeout中的代码块,输出2,然后将promise.then添加到本轮循环末尾清空微任务,输出3三、浏览器与Node.js的事件循环差异区别对比

对于两者的区别,来张瞟来的截图:

这个例子的代码如下:

setTimeout(()=>{   console.log('1');   Promise.resolve().then(function() {		console.log('2'); 	});});setTimeout(()=>{   console.log('3');   Promise.resolve().then(function() {		console.log('4');   });});

这段代码在浏览器和nodejs中的输出结果分别是什么呢?

通过前面对浏览事件循环的了解,你应该很容易得出在浏览器中的输出结果是: 1234

那在nodejs中的输出结果是什么呢?结果是在nodejs的 v11.x 之前输出1324。这之间的原因是浏览器有非常多的用户交互事件,为了用户体验更加流畅,必须均匀的处理宏任务和微任务,而在nodejs中由于并没有用户交互事件,为了保证异步事件能够被均等的执行,因此设计的初衷就是先清空宏任务队列再清空微任务队列。

不过你应该注意到,我上面只说了在 nodejs的 v11.x 之前输出1324,但是nodejs这个特性在社区经历了一波开发者的吐槽之后,node官方在 v11 这个版本紧急修复了这个问题。所以在 v11.x 以上版本执行以上代码会得到在浏览器中一样的结果。

setImmediate

先来张瞟来的截图:

我们再来一个例子:

setTimeout(()=>{	console.log('1');	Promise.resolve().then(() => console.log('2'));});setTimeout(()=>{  console.log('3');  Promise.resolve().then(() => console.log('4'));});setImmediate(() => {	console.log('5');   Promise.resolve().then(() => console.log('6'));});setImmediate(() => {	console.log('7');   Promise.resolve().then(() => console.log('8'));});

以上代码在nodejsV13.x中的执行结果是12345678,接下来我们把顺序调换一下,在第二个位置插入setImmediate

setTimeout(()=>{	console.log('1');	Promise.resolve().then(() => console.log('2'));});setImmediate(() => {	console.log('3');   Promise.resolve().then(() => console.log('4'));});setTimeout(()=>{  console.log('5');  Promise.resolve().then(() => console.log('6'));});setImmediate(() => {	console.log('7');   Promise.resolve().then(() => console.log('8'));});

执行结果有一定的概率是12347856,也有一定的概率是 12563478

为啥不同的顺序会得到不同的结果呢?这是由于setTImeout的精度问题导致的,到了这个级别的时间精度,代码执行的时间可能都会导致结果的不同。下面这张截图是nodejs官方文档对于事件循环顺序的展示:

其中timers阶段是用于执行setTimeout事件的,check阶段是用于执行setImmediate事件的。Nodejs官方这个所谓事件循环过程,其实只是完整的事件循环中Node.js的多个外部队列相互之间的优先级。setTimeout是由event loop检测系统时间是否到点然后向时间队列插入一个事件,然后调用事件的回调方法。而setImmediate是监控UI线程的调用栈,一旦调用栈为空则将回调压栈。

讲了这么多,其实对于上面setTimeout和setImmediate的对比结果还是有点模糊

推测:对于setImmediate的延时有时比setTimeout的要长,由于setImmediate要先监控调用栈,若调用栈为空才压栈,那么在压栈之前event loop已经将setTimeout事件的回调函数压栈了。

好了,以上是这次分享的所有内容,对于后面setTimeout和setImmedate的对比没有的出一个明确的结果,有兴趣的可以一起讨论。

标签: #historyapiajax报错