浏览器环境下

image.png不要狭隘的理解宏任务！不单是定时器等产生的！执行脚本代码本身就是一个宏任务，或者叫task(任务)更合适，就不要叫宏任务了。

setTimeout等产生的异步回调是在下一次eventloop里加到执行栈上执行的，所以效果上类似于在当前页面渲染更新完毕后才执行的。

总之，浏览器里有 JS 引擎做 JS 代码的执行，利用注入的浏览器 API 完成功能，有渲染引擎做页面渲染，两者都比较纯粹，需要一个调度的方式，就是 event loop。 event loop 实现了 task 和 急事处理机制 microtask，而且每次 loop 结束会 check 是否要渲染，渲染之前会有 requestAnimationFrames 生命周期。 帧刷新不能被拖延否则会卡顿甚至掉帧，所以就需要 JS 代码里面不要做过多计算，于是有了 requestIdleCallback 的 api，希望在每次 check 完发现还有时间就执行，没时间就不执行（这个deadline的时间也作为参数让 js 代码自己判断），为了避免一直没时间，还提供了 timeout 参数强制执行。 防止计算时间过长导致渲染掉帧是 ui 框架一直关注的问题，就是怎么不阻塞渲染，让逻辑能够拆成帧间隔时间内能够执行完的小块。浏览器提供了 idelcallback 的 api，很多 ui 框架也通过递归改循环然后记录状态等方式实现了计算量的拆分，目的只有一个：loop 内的逻辑执行不能阻塞 check，也就是不能阻塞渲染引擎做帧刷新。所以不管是 JS 代码宏微任务、 requestAnimationFrame、requestIdleCallback 都不能计算时间太长。这个问题是前端开发的持续性阵痛。

这段引用中有点小错，应该是：一帧可能对应多次tick/loop, 但是只能对应一次RAF,渲染,RIC

所以 Event Loop 执行顺序如下所示：

  • 首先执行同步代码，这属于宏任务
  • 当执行完所有同步代码后，执行栈为空，查询是否有异步代码需要执行
  • 执行所有微任务
  • 当执行完所有微任务后，如有必要会渲染页面
  • 然后开始下一轮 Event Loop，执行宏任务中的异步代码，也就是 setTimeout 中的回调函数

关于jspromise:Js引擎为了让microtask尽快的输出，做了一些优化，连续的多个then(3个)如果没有reject或者resolve会交替执行then而不至于让一个堵太久完成用户无响应，不单单v8这样其他引擎也是这样，因为其实promuse内部状态已经结束了。
这块在v8源码里有完整的体现,以前用java写的,后来用c++从引擎层面修改了,tq辅助实现.

微任务Microtasks 的运行时机：当 V8 执行完调用要返回 Blink 时，由于 MicrotasksScope 作用域失效，在其析构函数中检查 JS 调用栈是否为空，如果为空的话就会运行 Microtasks。