6.微任务和宏任务

宏任务

• 页面中的大部分任务都是在主线程上执行的

  • 渲染事件（如解析 DOM、计算布局、绘制）；
  • 用户交互事件（如鼠标点击、滚动页面、放大缩小等）；
  • JavaScript 脚本执行事件；
  • 网络请求完成、文件读写完成事件。

• 为了协调这些任务有条不紊地在主线程上执行，页面进程引入了消息队列和事件循环机制，渲染进程内部会维护多个消息队列，比如延迟执行队列和普通的消息队列。然后主线程采用一个 for 循环，不断地从这些任务队列中取出任务并执行任务。我们把这些消息队列中的任务称为宏任务。

• 消息队列中的任务是通过事件循环系统来执行。事件循环机制大致流程：

  • 先从多个消息队列中选出一个最老的任务，这个任务称为 oldestTask；
  • 然后循环系统记录任务开始执行的时间，并把这个 oldestTask 设置为当前正在执行的任务；
  • 当任务执行完成之后，删除当前正在执行的任务，并从对应的消息队列中删除掉这个 oldestTask；
  • 最后统计执行完成的时长等信息。
  • 以上就是消息队列中宏任务的执行过程。

• 宏任务可以满足大部分的日常需求，不过如果有对时间精度要求较高的需求，宏任务就难以胜任了。-> 为什么宏任务难以满足对时间精度要求较高的任务 ?

  • 页面的渲染事件、各种 IO 的完成事件、执行 JavaScript 脚本的事件、用户交互的事件等都随时有可能被添加到消息队列中，而且添加事件是由系统操作的，JavaScript 代码不能准确掌控任务要添加到队列中的位置，控制不了任务在消息队列中的位置，所以很难控制开始执行任务的时间。
  • setTimeout 函数触发的回调函数都是宏任务。

微任务

• 随着浏览器的应用领域越来越广泛，消息队列中这种粗时间颗粒度的任务已经不能胜任部分领域的需求，所以又出现了一种新的技术——微任务。微任务可以在实时性和效率之间做一个有效的权衡。

• 基于微任务的技术

  • MutationObserver
  • Promise

• 异步回调

  • 第一种是把异步回调函数封装成一个宏任务，添加到消息队列尾部，当循环系统执行到该任务的时候执行回调函数。
    • setTimeout 和 XMLHttpRequest 的回调函数都是通过这种方式来实现的。
  • 第二种方式的执行时机是在主函数执行结束之后、当前宏任务结束之前执行回调函数，这通常都是以微任务形式体现的。

• 微任务的定义

  • 微任务就是一个需要异步执行的函数，执行时机是在主函数执行结束之后、当前宏任务结束之前。

• 微任务系统的工作原理

  • V8 引擎的层面分析：
    • 当 JavaScript 执行一段脚本的时候，V8 会为其创建一个全局执行上下文，在创建全局执行上下文的同时，V8 引擎也会在内部创建一个微任务队列。
    • 微任务队列就是用来存放微任务的。
    • 在当前宏任务执行的过程中，有时候会产生多个微任务，这时候就需要使用这个微任务队列来保存这些微任务。
    • 不过这个微任务队列是给 V8 引擎内部使用的，所以无法通过 JavaScript 直接访问的。
    • 也就是说每个宏任务都关联了一个微任务队列。

• 微任务产生的时机和执行微任务队列的时机。

  • 第一种方式是使用 MutationObserver 监控某个 DOM 节点，然后再通过 JavaScript 来修改这个节点，或者为这个节点添加、删除部分子节点，当 DOM 节点发生变化时，就会产生 DOM 变化记录的微任务。
  • 第二种方式是使用 Promise，当调用 Promise.resolve() 或者 Promise.reject() 的时候，也会产生微任务。

• 微任务队列是何时被执行的？

  • 在当前宏任务中的 JavaScript 快执行完成时，也就在 JavaScript 引擎准备退出全局执行上下文并清空调用栈的时候，JavaScript 引擎会检查全局执行上下文中的微任务队列，然后按照顺序执行队列中的微任务。
  • WHATWG 把执行微任务的时间点称为检查点。
  • 如果在执行微任务的过程中，产生了新的微任务，同样会将该微任务添加到微任务队列中，V8 引擎一直循环执行微任务队列中的任务，直到队列为空才算执行结束。也就是说在执行微任务过程中产生的新的微任务并不会推迟到下个宏任务中执行，而是在当前的宏任务中继续执行。
    
    

• 该示意图是在执行一个 ParseHTML 的宏任务，在执行过程中，遇到了 JavaScript 脚本，那么就暂停解析流程，进入到 JavaScript 的执行环境。从图中可以看到，全局上下文中包含了微任务列表。

• 在 JavaScript 脚本的后续执行过程中，分别通过 Promise 和 removeChild 创建了两个微任务，并被添加到微任务列表中。接着 JavaScript 执行结束，准备退出全局执行上下文，这时候就到了检查点了，JavaScript 引擎会检查微任务列表，发现微任务列表中有微任务，那么接下来，依次执行这两个微任务。等微任务队列清空之后，就退出全局执行上下文。

• 以上就是微任务的工作流程，从上面分析可以得出如下几个结论：

  • 微任务和宏任务是绑定的，每个宏任务在执行时，会创建自己的微任务队列。
  • 微任务的执行时长会影响到当前宏任务的时长。
  • 在一个宏任务中，分别创建一个用于回调的宏任务和微任务，无论什么情况下，微任务都早于宏任务执行。

监听 DOM 变化方法演变

• 微任务如何应用在 MutationObserver 中

• MutationObserver

  • MutationObserver 是用来监听 DOM 变化的一套方法，而监听 DOM 变化一直是前端工程师一项非常核心的需求。
  • MutationObserver API 可以用来监视 DOM 的变化，包括属性的变化、节点的增减、内容的变化等。
  • MutationObserver 将响应函数改成异步调用，可以不用在每次 DOM 变化都触发异步调用，而是等多次 DOM 变化后，一次触发异步调用，并且还会使用一个数据结构来记录这期间所有的 DOM 变化。这样即使频繁地操纵 DOM，也不会对性能造成太大的影响。(Mutation Event则造成了严重的性能问题。因为 DOM 一旦发生变化，就会立即调用 JavaScript 接口。)
  • MutationObserver 通过异步调用和减少触发次数来缓解了性能问题。
  • 关于保持消息通知的及时性则使用了微任务。在每次 DOM 节点发生变化的时候，渲染引擎将变化记录封装成微任务，并将微任务添加进当前的微任务队列中。
  • 所以 MutationObserver 采用了“异步 + 微任务”的策略。
    • 通过异步操作解决了同步操作的性能问题；
    • 通过微任务解决了实时性的问题。

• 许多 Web 应用都利用 HTML 与 JavaScript 构建其自定义控件，与一些内置控件不同，这些控件不是固有的。为了与内置控件一起良好地工作，这些控件必须能够适应内容更改、响应事件和用户交互。因此，Web 应用需要监视 DOM 变化并及时地做出响应。

笔记内容来自极客时间李兵老师的《浏览器工作原理与实践》 学习收获了很多 感谢老师