javascript事件循环(浏览器端、node端)
为什么要了解js中的事件循环
javascript是一种基于事件的单线程、异步、非阻塞编程语言,我经常在看书或者浏览别人博客的时候看到这种说法,可是之前一直没有深入理解过,只知道javascript中经常使用各种回调函数,比如浏览器端的各种事件回调(点击事件、滚动事件等)、ajax请求回调、setTimeout回调以及react16的内核fiber中用到的requestAnimationFrame、promise回调、node端fs模块异步读取文件内容回调、process模块的nextTick等等。最近有时间浏览了各种资料(后面有各种相关资料的链接),终于明白所有的这些内容其实都离不开javascript事件循环,而浏览器端的事件循环又与node端的事件循环有较大区别,下面分别介绍下。
浏览器 vs node
自从有了node,javascript既可以运行在浏览器端又可以运行在服务端,以chrome浏览器为例,相同点是都基于v8引擎,不同的是浏览器端实现了页面渲染、而mode端则提供了一些服务端会用到的特性,比如fs、process等模块,同时node端为了实现跨平台,底层使用libuv来兼容linux、windows、 macOS三大操作系统。因此虽然都实现了javascript的异步、非阻塞特性,但是却有有不少不同之处。
浏览器端
无论是在浏览器端还是node端,线程入口都是一个javascript脚本文件,整个脚本文件从第一行开始到最后运行完成可以看作是一个entry task,即初始化任务,下图task中第一项即为该过程。初始化过程中肯定会注册不少异步事件,比如常见的setTimeout、onClick、promise等,这些异步事件执行中又有可能注册更多异步事件。所有的这些异步任务都是在事件循环一次次的循环中得到执行,而这些异步任务又可以分为两大类,即microtask和task(或macrotask)。那么一次事件循环中会执行多少个异步任务?microtask和task的执行先后顺序是什么呢?看下图。
先忽略图中的红色部分(渲染过程,后面再介绍),顺时针方向即为事件循环方向,可以看出每次循环会先后执行两类任务,
task和microtask,每一类任务都由一个队列组成,其中task主要包括如下几类任务:
- index.js(entry)
setTimeoutsetInterval- 网络I/O
而microtask主要包括:
promiseMutationObserver
因此microtask的执行事件结点是在两次task执行间隙。前面说了,每类任务都由一个队列组成,这其实是一种生产者-消费者模型,事件的注册过程即为任务生产过程,任务的执行过程即为事件的消费过程。那么每次轮到一类任务执行各个队列会出队多少个任务来执行呢?图中我已经标明,task队列每次出队一项任务来执行,执行完成之后开始执行microtask;而microtask则每次都把所有任务执行完成,然后才会继续执行task。注意,这里说的microtask每次都把所有任务执行完成会包括当前轮次执行的过程中新添加进来的任务,所以,下面的这段代码中的setTimeout回调任务将永远得不到执行:
setTimeout(() => {
console.log('run setTimout callback');
}, 0);
function promiseLoop() {
console.log('run promise callback');
return Promise.resolve().then(() => {
return promiseLoop();
});
}
promiseLoop();
现在回过头来再看上图中的粉红色虚线部分,该过程表示的是浏览器渲染过程,比如dom元素的style、layout以及position这些渲染,那为什么用虚线表示呢?是因为该部分的调度是由浏览器控制,而且是以60HZ的频率调度,之所以是60HZ是为了能满足人眼视觉效果的同时尽量低频的调度,如果浏览器一刻不停的频繁渲染,那么不仅人眼观察不到界面的变化效果(就如同夏天电扇转太快人眼分辨不出来),而且耗费计算资源。因此上图中渲染过程用虚线表示不一定每次事件循环都会执行渲染过程。
仔细看虚线框起来的渲染过程,可以看到在执行渲染之前可以执行一个回调函数requestAnimationFrame,react16的内核fiber即使用了该钩子函数来实现更加精细的任务调度算法,以提升前端页面性能。使用该钩子函数注册的回调函数同task回调和microtask回调一样,会进入专属的事件队列。
现在总结一下浏览器端的事件队列,共包括三个事件队列:task队列、requestAnimationFrame队列以及microtask队列,javascript脚本加载完成后首先执行第一个task队列任务,即初始化任务,然后执行所有microtask队列任务,接着再次执行第二个task队列任务,以此类推,这其中穿插着60HZ的渲染过程。先执行谁后执行谁现在了解清楚了,可是到每个事件队列执行的轮次时,分别会有多少个事件出队执行呢?答案见下图(截图自Jake Archibald大神的JSConf演讲视频):
可以看出,在一次事件循环中:普通
task每次出队一项回调函数去执行,requestAnimationFrame每次出队所有当前队列的回调函数去执行,microtask每次出队所有当前队列的回调函数以及自己轮次执行过程中又新增到队尾的回调函数。这三种不同的调度方式正好覆盖了所有场景。
实践一下
TODO:用前面介绍的模型解释一些demo
node端
前面介绍了下浏览器端的事件循环,涉及到task和microtask,其实node端的异步任务也包括这些,只不过node端的task划分的更细,如下图所示,node端的task可以分为4类任务队列:
- index.js(entry)、
setTimeout、setInterval - 网络I/O、
fs(disk)、child_process setImmediate- close事件
而microtask包括:
process.nextTickpromise
node端task分为了4类队列,每次事件循环会依次执行该4类事件队列。而每执行完一个task队列就会接着执行microtask队列,然后再接着执行下一个task队列。因此microtask队列的执行是穿插在各个类形的task之间的。
node端与浏览器端事件循环的一个很重要的不同点是,浏览器端task队列每轮事件循环仅出队一个回调函数去执行接着去执行microtask,而node端只要轮到执行task,则会跟执行完队列中的所有当前任务,但是当前轮次新添加到队尾的任务则会等到下一轮次才会执行,该机制与浏览器端的requestAnimationFrame的调度机制时一样的。
总结一下node端的事件循环,共包括4类task事件队列与2类microtask事件队列,microtask穿插在task之间执行。task每次轮到执行会将当前队列中的所有回调函数出队执行,而microtask的调度机制则与浏览器端一样,每次轮到执行都会出队所有当前队列的回调函数以及自己轮次执行过程中又新增到队尾的回调函数去执行。与浏览器端不一样的是node端的microtask包括process.nextTick和promise两类。
实践一下
TODO:用前面介绍的模型解释一些demo
引用
本篇总结主要参考了如下资源,强烈推荐浏览阅读:
- Jake Archibald: In The Loop - JSConf.Asia 2018
- Philip Roberts: What the heck is the event loop anyway? - JSConf.EU 2014
- Everything You Need to Know About Node.js Event Loop - Bert Belder, IBM
- Event Loop and the Big Picture — NodeJS Event Loop Part 1
- Timers, Immediates and Process.nextTick— NodeJS Event Loop Part 2
- Promises, Next-Ticks and Immediates— NodeJS Event Loop Part 3
- Handling IO — NodeJS Event Loop Part 4
- Event Loop Best Practices — NodeJS Event Loop Part 5