- 浏览器渲染。
▐ 案例分析
根据上述的处理模型,我们可以来看以下例子:
console.log(‘script start’);
setTimeout(function() {
console.log(‘setTimeout’);
}, 0);
Promise.resolve().then(function() {
console.log(‘promise1’);
}).then(function() {
console.log(‘promise2’);
});
console.log(‘script end’);
输出结果:
script start
script end
promise1
promise2
setTimeout
对应的处理过程则是:
-
执行 console.log (输出 script start)
-
遇到 setTimeout 加入外部队列
-
遇到两个 Promise 的 then 加入内部队列
-
遇到 console.log 直接执行(输出 script end)
-
内部队列中的任务挨个执行完 (输出 promise1 和 promise2)
-
外部队列中的任务执行 (输出 setTimeout)
只要理解了外部队列与内部队列的概念,再看这类问题就会变得很简单,我们再简单扩展看看:
setTimeout(() => {
console.log(‘setTimeout1’)
})
Promise.resolve().then(() => {
console.log(‘promise1’)
})
setTimeout(() => {
console.log(‘setTimeout2’)
})
Promise.resolve().then(() => {
console.log(‘promise2’)
})
Promise.resolve().then(() => {
console.log(‘promise3’)
})
console.log(‘script end’);
结果输出:
script end
promise1
promise2
promise3
setTimeout1
setTimeout2
可以发现加入内部队列的顺序和时间虽然后差异,但是轮到内部队列执行的时候,一定会先全部执行完内部队列才会继续往下走去执行外部队列的任务。
最后我们再看一个引入了 HTML 渲染的例子:
通过这个例子,我们就可以发现,渲染过程很明显分成三个阶段:
-
JavaScript 执行完毕 innerText 首先加上 [end 10001]
-
内部队列:Promise 的 then 全部任务执行完毕,往 innerText 上追加了很长一段字符串
-
HTML 渲染:1 和 2 追加到 innerText 上的内容同时渲染
-
外部队列:挨个执行 setTimeout 中追加到 innerText 的内容
-
HTML 渲染:将 4 中的内容渲染。
-
回到第 4 步走外部队列的流程(内部队列已清空)
▐ script 事件是外部队列
有的同学看完上面的几个例子之后可能有个问题,为什么 JavaScript 代码执行到 script end 之后,是先执行内部队列然后再执行外部队列的任务?
这里不得不把上文总出现过的 HTML 事件循环标准 再拉出来一遍:
To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this p…
看到这里,大家可能就反应过来了,scripts 执行也是一个事件,我们只要归类一下就会发现 JavaScript 的执行也是一个浏览器发起的外部事件。所以本质的执行顺序还是:
-
一次外部事件
-
所有内部事件
-
HTML 渲染
-
回到到 1
浏览器与 Node.js 的事件循环差异
根据本文开头我们讨论的事件循环起源,很容易理解为什么浏览器与 Node.js 的事件循环会存在差异。如果说浏览端是将 JavaScript 集成到 HTML 的事件循环之中,那么 Node.js 则是将 JavaScript 集成到 libuv 的 I/O 循环之中。
简而言之,二者都是把 JavaScript 集成到他们各自的环境中,但是 HTML (浏览器端) 与 libuv (服务端) 面对的场景有很大的差异。首先能直观感受到的区别是:
-
事件循环的过程没有 HTML 渲染。只剩下了外部队列和内部队列这两个部分。
-
外部队列的事件源不同。Node.js 端没有了鼠标等外设但是新增了文件等 IO。
-
内部队列的事件仅剩下 Promise 的 then 和 catch。
至于内在的差异,有一个很重要的地方是 Node.js (libuv)在最初设计的时候是允许执行多次外部的事件再切换到内部队列的,而浏览器端一次事件循环只允许执行一次外部事件。这个经典的内在差异,可以通过以下例子来观察:
setTimeout(()=>{
console.log(‘timer1’);
Promise.resolve().then(function() {
console.log(‘promise1’);
});
});
setTimeout(()=>{
console.log(‘timer2’);
Promise.resolve().then(function() {
console.log(‘promise2’);
});
});
这个例子在浏览器端执行的结果是 timer1 -> promise1 -> timer2 -> promise2,而在 Node.js 早期版本(11 之前)执行的 《大厂前端面试题解析+Web核心总结学习笔记+企业项目实战源码+最新高清讲解视频》无偿开源 徽信搜索公众号【编程进阶路】 结果却是 timer1 -> timer2 -> promise1 -> promise2。
究其原因,主要是因为浏览器端有外部队列一次事件循环只能执行一个的限制,而在 Node.js 中则放开了这个限制,允许外部队列中所有任务都执行完再切换到内部队列。所以他们的情况对应为:
▐ 浏览器端
-
外部队列:代码执行,两个 timeout 加入外部队列
-
内部队列:空
-
外部队列:第一个 timeout 执行,promise 加入内部队列
-
内部队列:执行第一个 promise
-
外部队列:第二个 timeout 执行,promise 加入内部队列
-
内部队列:执行第二个 promise
▐ Node.js 服务端
-
外部队列:代码执行,两个 timeout 加入外部队列
-
内部队列:空
-
外部队列:两个 timeout 都执行完
-
内部队列:两个 promise 都执行完
虽然 Node.js 的这个问题在 11 之后的版本里修复了,但是为了继续探究这个影响,我们引入一个新的外部事件 setImmediate。这个方法目前是 Node.js 独有的,浏览器端没有。
setImmediate 的引入是为了解决 setTimeout 的精度问题,由于 setTimeout 指定的延迟时间是毫秒(ms)但实际一次时间循环的时间可能是纳秒级的,所以在一次事件循环的多个外部队列中,找到某一个队列直接执行其中的 callback 可以得到比 setTimeout 更早执行的效果。我们继续以开始的场景构造一个例子,并在 Node.js 10.x 的版本上执行(存在一次事件循环执行多次外部事件):
setTimeout(()=>{
console.log(‘setTimeout1’);
Promise.resolve().then(() => console.log(‘promise1’));
});
setTimeout(()=>{
console.log(‘setTimeout2’);
Promise.resolve().then(() => console.log(‘promise2’));
});
setImmediate(() => {
console.log(‘setImmediate1’);
Promise.resolve().then(() => console.log(‘promise3’));
});
setImmediate(() => {
console.log(‘setImmediate2’);
Promise.resolve().then(() => console.log(‘promise4’));
});
输出结果:
setImmediate1setImmediate2promise3promise4setTimeout1setTimeout2promise1
promise2
根据这个执行结果 [3],我们可以推测出 Node.js 中的事件循环与浏览器类似,也是外部队列与内部队列的循环,而 setImmediate 在另外一个外部队列中。
接下来,我们再来看一下当 Node.js 在与浏览器端对齐了事件循环的事件之后,这个例子的执行结果为:
setImmediate1
promise3
setImmediate2
promise4
setTimeout1
promise1
setTimeout2
promise2
其中主要有两点需要关注,一是外部列队在每次事件循环只执行了一个,另一个是 Node.js 的固定了多个外部队列的优先级。setImmediate 的外部队列没有执行完的时候,是不会执行 timeout 的外部队列的。了解了这个点之后,Node.js 的事件循环就变得很简单了,我们可以看下 Node.js 官方文档中对于事件循环顺序的展示:
其中 check 阶段是用于执行 setImmediate 事件的。结合本文上面的推论我们可以知道,Node.js 官方这个所谓事件循环过程,其实只是完整的事件循环中 Node.js 的多个外部队列相互之间的优先级顺序。
我们可以在加入一个 poll 阶段的例子来看这个循环: