event loop，是一个比较抽象的东西。主要因为两个方面
- 文档看上去很复杂；
- 难以眼见为实。如何确认自己真的明白整个过程。如何把event loop的理论联系到实际，或者更进一步，如何用于编程和debug。
作为一个习惯了所见即所得的前端，我希望能够确认我yy出来的流程是否和浏览器执行的真实情况一致，同时能够真正作用于编程和debug中
console.log？
最初接触event loop(之前写（翻译）过的一篇博客)，我曾经尝试过console.log 。效果其实并没有很好，更像是，我大约知道了这个理论，然后根据现实的情况强行解释它。同时中间还有很大的不确定性。比如说如何确认浏览器是先执行microtaks还是先执行渲染，如何确认一个event loop已经执行完了。
那，还有啥子办法？
最近看了几场jsconf eu关于chrome的performance的分享，忽然灵光一现，可以利用chrome dev tool>performance来验证整个过程
event loop
文档关于event loop的执行说明如下图：
task queue包含：
- Events
- Parsing
- Callbacks(setTimeout, etc)
- Using a resource
- Reacting to DOM manipulation(node.inserBefore, etc)
（每个task有自己的task source，浏览器有相当大的裁量权来决定哪个task source过来的task先执行。）
执行完一个taskQueue，就会执行一次microtask，把microtask queue全部清干净
理论看上去是很清晰的，然而，仍有地方是很容易迷惑的，比如说：
- 如何才算做一个queue？考虑以下代码
// Promise runs in microtask
Promise.resolve().then(() => { console.log('microtask ran') })
// is it a queue?
const div = document.querySelector('div')
document.body.insertBefore(document.createElement('div'), div)
// queue ends?
console.log('will microtask run before me?')
结果似乎不是这样：
可以看到，只有在log结束的时候，也就是在整个执行栈空了的时候才执行了microtask。wait，这和(我理解的)文档说的不一样！！难道不是dom manipulation执行完了就执行microtask么？
so, what's a queue?
根据上面，似乎是把一个执行栈都执行完了，就算一个queue执行完了，就可以进行microtask。
let's have a try
function log (type) {
Promise.resolve().then(() => {
console.log(`microtask added by ${type} runs`)
})
console.log(`start log[${Date.now()}]: ${type}`)
}
setTimeout(log.bind(null, 'setTimeout'))
document.addEventListener('DOMContentLoaded', log.bind(null, 'DOMContentLoaded'))
log('global 1')
log('global 2')
确认了两件事情：
- 当前执行栈空时才执行microtask
- setTimeout会在其他task queue（此处是Parsing）之后，再执行
放大Parse HTML，我们可以看到：
microtask执行在render（recalculate style和layout）之前
microtask
文档:
看上去还蛮清晰的
如果在一个microtask里面又指定了一个microtask呢？
考虑以下代码:
Promise.resolve().then(log.bind(null, 'promise'))
可以看到，microtask里面又指定了一个microtask，会顺序执行，而不是留到下一个microtask checkPoint执行
render pipeline
实际上对于前面的两个理论的验证，单纯靠console.log，也是可以印证的，但是渲染相关，就很难了。
文档
图片来自render process model
考虑以下代码：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>event loop</title>
<style>
body {
height: 2000px;
background: lightgreen;
}
</style>
</head>
<body>
<div class="animate">lulala</div>
<script src="./test.js"></script>
</body>
</html>
// your test.js
document.addEventListener('DOMContentLoaded', () => {
function log (type) {
Promise.resolve().then(() => {
console.log(`microtask added by ${type} runs`)
})
console.log(`start log[${Date.now()}]: ${type}`)
}
setTimeout(() => {
window.requestAnimationFrame(log.bind(null, 'rAF'))
window.addEventListener('scroll', log.bind(null, 'scroll'))
window.scrollTo(0, 3000)
})
log('global')
})
可以看到scroll是在rAF之前被触发的，之后便开始了update layer tree和paint
wait，竟然发现scroll和rAF之后，都触发了microtasks！！
conclusion
哈，原本是想写一篇深入event loop的文章，写着变成了如何使用performance观察event loop🤦♂
不过在整个尝试的过程里面，还破除了一些以前模棱两可的迷信，比如说“不要老是去拿元素属性，会触发重排或者重绘的”，其实不一定的哦，设置了动画或者对元素进行了class增删，然后取元素宽高之类的属性，的确会导致重排或者重绘的计算。但是如果对元素（包括所有会影响该元素的操作）啥也没做，只是取值，并不会触发什么事情。
🌝
