一、事件循环
我们都知道,Js引擎是单线程的,也就是说每次执行一堆程序,必须是一个执行完再去执行另一个。那可能有人要问了:平时我们开启setTimeout定时器,也没见影响到后面程序的运行啊!是因为javascript从诞生之日起就是一门单线程的非阻塞的脚本语言。而它的非阻塞性是通过异步任务来实现的,可见setTimeout就是一个异步任务。
那么从上图我们就可以得知:实现异步任务,就需要借助浏览器内置webAPIs模块(浏览器分线程)来执行异步任务。
setTimeout(()=>{
console.log('我是异步')
},2000)
console.log('我是同步')
如上代码执行过程:
- 浏览器解析Js代码到
setTimeout
函数时,函数入栈
,发现该函数为异步代码,将它放入webAPIs
浏览器分线程中开始计时
。 - 浏览器继续Js代码到
console.log('我是同步')
,发现是同步
代码,直接
出栈执行
输出“我是同步” - 过了近两秒,浏览器分线程(webAPIs),将计时完成的定时器函数放入
callback queue
回调队列(消息队列),浏览器开始遍历回调队列,将定时器函数放入栈中立即执行,控制台打印“我是异步”
此次操作,完成一个事件循环。
注意:只有执行栈里没有要执行的程序时,浏览器才会去轮询回调队列(若回调队列里有回调函数,将它拉进执行栈执行)
二、宏任务/微任务
异步代码的执行顺序是有差异的,并不是由上到下挨个执行。因为异步函数又有宏任务与微任务之分。
执行顺序为:同步任务 ——> 异步微任务 ——> 异步宏任务
宏任务:
新程序或子程序被直接执行
时间的回调函数
setTimeout和setInterval的回调
微任务:
1.Promise.then() .catch() .finally()
2. MutationObserver
3. Object.observe
无渲染
// 宏任务
console.log('1')
// setTimeout 的回调是 宏任务,进入回调队列排队
setTimeout(() => {
// 宏任务
console.log('4')
// setTimeout 的回调是 宏任务2,进入回调队列排队
setTimeout(() => {
console.log('7')
}, 0)
// Promise 的回调是 微任务,本轮调用末尾直接执行
Promise.resolve()
.then(() => {
console.log('6')
})
console.log('5')
}, 0)
// Promise 的回调是 微任务,本轮调用末尾直接执行
Promise.resolve()
.then(() => {
console.log('3')
})
console.log('2')
以上代码执行循序为1~7正序输出。
每一个宏任务,后面都可以跟一个微任务队列,如果微任务队列中有指令或方法,那么就会执行;如果没有,则开始执行下一个宏任务,直到所有的宏任务执行完为止,微任务相当于宏任务的小尾巴
所以,这并没有违背回调队列的先进先出原则,一个宏任务中如果伴随着微任务,那么就先执行微任务,宏任务先放置,等到后面的微任务一个个都执行完后,再开始执行宏任务!
其实浏览器执行Js代码的完整顺序应该是:同步任务 ——> 异步微任务 ——> DOM渲染页面
——>异步宏任务
没错,在微任务与宏任务之间,浏览器会进行一次DOM渲染,如下案例:
有渲染
//向body添加h1节点,内容为Hello
const $content = $('<h1>Hello</h1>')
$('body').append($content)
console.log(1);
Promise.resolve().then(() => {
console.log('2.promise');
alert('promise then')
})
setTimeout(() => {
console.log('3 setTimeout');
alert('setTimeout')
}, 0);
console.log(4);
执行过程:
step1:
点击aler窗口确定后,step2:
由此证明结论:同步任务 ——> 异步微任务 ——> DOM渲染页面
——>异步宏任务