前言

眾所周知，為了與瀏覽器進行互動，Javascript是一門非阻塞單執行緒指令碼語言。
複製程式碼

1. 為何單執行緒？ 因為如果在DOM操作中，有兩個執行緒一個新增節點，一個刪除節點，瀏覽器並不知道以哪個為準，所以只能選擇一個主執行緒來執行程式碼，以防止衝突。雖然如今新增了webworker等新技術，但其依然只是主執行緒的子執行緒，並不能執行諸如I/O類的操作。長期來看，JS將一直是單執行緒。

2. 為何非阻塞？因為單執行緒意味著任務需要排隊，任務按順序執行，如果一個任務很耗時，下一個任務不得不等待。所以為了避免這種阻塞，我們需要一種非阻塞機制。這種非阻塞機制是一種非同步機制，即需要等待的任務不會阻塞主執行棧中同步任務的執行。這種機制是如下執行的：

   • 所有同步任務都在主執行緒上執行，形成一個執行棧（execution context stack）
   • 等待任務的回撥結果進入一種任務佇列(task queue)。
   • 當主執行棧中的同步任務執行完畢後才會讀取任務佇列，任務佇列中的非同步任務（即之前等待任務的回撥結果）會塞入主執行棧，
   • 非同步任務執行完畢後會再次進入下一個迴圈。此即為今天文章的主角事件迴圈(Event Loop)

   用一張圖展示這個過程：

   

正文

1.macro task與micro task

在實際情況中，上述的任務佇列(task queue)中的非同步任務分為兩種：微任務（micro task)和巨集任務（macro task)。

• micro task事件：Promises(瀏覽器實現的原生Promise)、MutationObserver、process.nextTick
  
  
• macro task事件：setTimeout、setInterval、setImmediate、I/O、UI rendering 這裡注意：script(整體程式碼)即一開始在主執行棧中的同步程式碼本質上也屬於macrotask，屬於第一個執行的task

microtask和macotask執行規則：

• macrotask按順序執行，瀏覽器的ui繪製會插在每個macrotask之間
• microtask按順序執行，會在如下情況下執行：
  • 每個callback之後，只要沒有其他的JS在主執行棧中
  • 每個macrotask結束時

下面來個簡單例子：

console.log(1);

setTimeout(function() {
  console.log(2);
}, 0);

new Promise(function(resolve,reject){
    console.log(3)
    resolve()
}).then(function() {
  console.log(4);
}).then(function() {
  console.log(5);
});

console.log(6);
複製程式碼

一步一步分析如下：

• 1.同步程式碼作為第一個macrotask,按順序輸出：1 3 6
• 2.microtask按順序執行：4 5
• 3.microtask清空後執行下一個macrotask：2

再來一個複雜的例子：

// Let's get hold of those elements
var outer = document.querySelector('.outer');
var inner = document.querySelector('.inner');

// Let's listen for attribute changes on the
// outer element
new MutationObserver(function() {
  console.log('mutate');
}).observe(outer, {
  attributes: true
});

// Here's a click listener…
function onClick() {
  console.log('click');

  setTimeout(function() {
    console.log('timeout');
  }, 0);

  Promise.resolve().then(function() {
    console.log('promise');
  });

  outer.setAttribute('data-random', Math.random());
}

// …which we'll attach to both elements
inner.addEventListener('click', onClick);
outer.addEventListener('click', onClick);
複製程式碼

假設我們建立一個有裡外兩部分的正方形盒子，裡外都繫結了點選事件，此時點選內部，程式碼會如何執行？一步一步分析如下：

• 1.觸發內部click事件，同步輸出：click
• 2.將setTimeout回撥結果放入macrotask佇列
• 3.將promise回撥結果放入microtask
• 4.將Mutation observers放入microtask佇列，主執行棧中onclick事件結束，主執行棧清空
• 5.依序執行microtask佇列中任務，輸出：promise mutate
• 6.注意此時事件冒泡，外部元素再次觸發onclick回撥，所以按照前5步再次輸出：click promise mutate（我們可以注意到事件冒泡甚至會在microtask中的任務執行之後，microtask優先順序非常高）
• 7.macrotask中第一個任務執行完畢，依次執行macrotask中剩下的任務輸出：timeout timeout

2.vue.nextTick實現

在 Vue.js 裡是資料驅動檢視變化，由於 JS 執行是單執行緒的，在一個 tick 的過程中，它可能會多次修改資料，但 Vue.js 並不會傻到每修改一次資料就去驅動一次檢視變化，它會把這些資料的修改全部 push 到一個佇列裡，然後內部呼叫 一次 nextTick 去更新檢視，所以資料到 DOM 檢視的變化是需要在下一個 tick 才能完成。這便是我們為什麼需要vue.nextTick.

這樣一個功能和事件迴圈非常相似，在每個 task 執行完以後，UI 都會重渲染，那麼很容易想到在 microtask 中就完成資料更新，當前 task 結束就可以得到最新的 UI 了。反之如果新建一個 task 來做資料更新，那麼渲染就會進行兩次。

所以在vue 2.4之前使用microtask實現nextTick，直接上原始碼

var counter = 1
var observer = new MutationObserver(nextTickHandler)
var textNode = document.createTextNode(String(counter))
observer.observe(textNode, {
    characterData: true
})
timerFunc = () => {
    counter = (counter + 1) % 2
    textNode.data = String(counter)
}
複製程式碼

可以看到使用了MutationObserver

然而到了vue 2.4之後卻混合使用microtask macrotask來實現，原始碼如下

/* @flow */
/* globals MessageChannel */

import { noop } from 'shared/util'
import { handleError } from './error'
import { isIOS, isNative } from './env'

const callbacks = []
let pending = false

function flushCallbacks () {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

// Here we have async deferring wrappers using both micro and macro tasks.
// In < 2.4 we used micro tasks everywhere, but there are some scenarios where
// micro tasks have too high a priority and fires in between supposedly
// sequential events (e.g. #4521, #6690) or even between bubbling of the same
// event (#6566). However, using macro tasks everywhere also has subtle problems
// when state is changed right before repaint (e.g. #6813, out-in transitions).
// Here we use micro task by default, but expose a way to force macro task when
// needed (e.g. in event handlers attached by v-on).
let microTimerFunc
let macroTimerFunc
let useMacroTask = false

// Determine (macro) Task defer implementation.
// Technically setImmediate should be the ideal choice, but it's only available
// in IE. The only polyfill that consistently queues the callback after all DOM
// events triggered in the same loop is by using MessageChannel.
/* istanbul ignore if */
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  macroTimerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else if (typeof MessageChannel !== 'undefined' && (
  isNative(MessageChannel) ||
  // PhantomJS
  MessageChannel.toString() === '[object MessageChannelConstructor]'
)) {
  const channel = new MessageChannel()
  const port = channel.port2
  channel.port1.onmessage = flushCallbacks
  macroTimerFunc = () => {
    port.postMessage(1)
  }
} else {
  /* istanbul ignore next */
  macroTimerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

// Determine MicroTask defer implementation.
/* istanbul ignore next, $flow-disable-line */
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  microTimerFunc = () => {
    p.then(flushCallbacks)
    // in problematic UIWebViews, Promise.then doesn't completely break, but
    // it can get stuck in a weird state where callbacks are pushed into the
    // microtask queue but the queue isn't being flushed, until the browser
    // needs to do some other work, e.g. handle a timer. Therefore we can
    // "force" the microtask queue to be flushed by adding an empty timer.
    if (isIOS) setTimeout(noop)
  }
} else {
  // fallback to macro
  microTimerFunc = macroTimerFunc
}

/**
 * Wrap a function so that if any code inside triggers state change,
 * the changes are queued using a Task instead of a MicroTask.
 */
export function withMacroTask (fn: Function): Function {
  return fn._withTask || (fn._withTask = function () {
    useMacroTask = true
    const res = fn.apply(null, arguments)
    useMacroTask = false
    return res
  })
}

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  callbacks.push(() => {
    if (cb) {
      try {
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })
  if (!pending) {
    pending = true
    if (useMacroTask) {
      macroTimerFunc()
    } else {
      microTimerFunc()
    }
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}
複製程式碼

可以看到使用setImmediate、MessageChannel等mascrotask事件來實現nextTick。

為什麼會如此修改，其實看之前的事件冒泡例子就可以知道，由於microtask優先順序太高，甚至會比冒泡快，所以會造成一些詭異的bug。如 issue #4521、#6690、#6556；但是如果全部都改成 macro task，對一些有重繪和動畫的場景也會有效能影響，如 issue #6813。所以最終 nextTick 採取的策略是預設走 micro task，對於一些 DOM 互動事件，如 v-on 繫結的事件回撥函式的處理，會強制走 macro task。

參考資料

• Tasks, microtasks, queues and schedules
• Vue.js 升級踩坑小記
• Vue 中如何使用 MutationObserver 做批量處理