Vue為何採用非同步渲染

Vue為何採用非同步渲染

Vue在更新DOM時是非同步執行的,只要偵聽到數據變化,Vue將開啟一個隊列,並緩衝在同一事件循環中發生的所有數據變更,如果同一個watcher被多次觸發,只會被推入到隊列中一次,這種在緩衝時去除重複數據對於避免不必要的計算和DOM操作是非常重要的,然後,在下一個的事件循環tick中,Vue刷新隊列並執行實際(已去重的)工作,Vue在內部對非同步隊列嘗試使用原生的Promise.thenMutationObserversetImmediate,如果執行環境不支援,則會採用setTimeout(fn, 0)代替。

描述

對於Vue為何採用非同步渲染,簡單來說就是為了提升性能,因為不採用非同步更新,在每次更新數據都會對當前組件進行重新渲染,為了性能考慮,Vue會在本輪數據更新後,再去非同步更新視圖,舉個例子,讓我們在一個方法內重複更新一個值。

this.msg = 1;
this.msg = 2;
this.msg = 3;

事實上,我們真正想要的其實只是最後一次更新而已,也就是說前三次DOM更新都是可以省略的,我們只需要等所有狀態都修改好了之後再進行渲染就可以減少一些性能損耗。
對於渲染方面的問題是很明確的,最終只渲染一次肯定比修改之後即渲染所耗費的性能少,在這裡我們還需要考慮一下非同步更新隊列的相關問題,假設我們現在是進行了相關處理使得每次更新數據只進行一次真實DOM渲染,來讓我們考慮非同步更新隊列的性能優化。
假設這裡是同步更新隊列,this.msg=1,大致會發生這些事: msg值更新 -> 觸發setter -> 觸發Watcherupdate -> 重新調用 render -> 生成新的vdom -> dom-diff -> dom更新,這裡的dom更新並不是渲染(即布局、繪製、合成等一系列步驟),而是更新記憶體中的DOM樹結構,之後再運行this.msg=2,再重複上述步驟,之後的第3次更新同樣會觸發相同的流程,等開始渲染的時候,最新的DOM樹中確實只會存在更新完成3,從這裡來看,前2次對msg的操作以及Vue內部對它的處理都是無用的操作,可以進行優化處理。
如果是非同步更新隊列,會是下面的情況,運行this.msg=1,並不是立即進行上面的流程,而是將對msg有依賴的Watcher都保存在隊列中,該隊列可能這樣[Watcher1, Watcher2...],當運行this.msg=2後,同樣是將對msg有依賴的Watcher保存到隊列中,Vue內部會做去重判斷,這次操作後,可以認為隊列數據沒有發生變化,第3次更新也是上面的過程,當然,你不可能只對msg有操作,你可能對該組件中的另一個屬性也有操作,比如this.otherMsg=othermessage,同樣會把對otherMsg有依賴的Watcher添加到非同步更新隊列中,因為有重複判斷操作,這個Watcher也只會在隊列中存在一次,本次非同步任務執行結束後,會進入下一個任務執行流程,其實就是遍歷非同步更新隊列中的每一個Watcher,觸發其update,然後進行重新調用render -> new vdom -> dom-diff -> dom更新等流程,但是這種方式和同步更新隊列相比,不管操作多少次msg Vue在內部只會進行一次重新調用真實更新流程,所以,對於非同步更新隊列不是節省了渲染成本,而是節省了Vue內部計算及DOM樹操作的成本,不管採用哪種方式,渲染確實只有一次。
此外,組件內部實際使用VirtualDOM進行渲染,也就是說,組件內部其實是不關心哪個狀態發生了變化,它只需要計算一次就可以得知哪些節點需要更新,也就是說,如果更改了N個狀態,其實只需要發送一個訊號就可以將DOM更新到最新,如果我們更新多個值。

this.msg = 1;
this.age = 2;
this.name = 3;

此處我們分三次修改了三種狀態,但其實Vue只會渲染一次,因為VIrtualDOM只需要一次就可以將整個組件的DOM更新到最新,它根本不會關心這個更新的訊號到底是從哪個具體的狀態發出來的。
而為了達到這個目的,我們需要將渲染操作推遲到所有的狀態都修改完成,為了做到這一點只需要將渲染操作推遲到本輪事件循環的最後或者下一輪事件循環,也就是說,只需要在本輪事件循環的最後,等前面更新狀態的語句都執行完之後,執行一次渲染操作,它就可以無視前面各種更新狀態的語法,無論前面寫了多少條更新狀態的語句,只在最後渲染一次就可以了。
將渲染推遲到本輪事件循環的最後執行渲染的時機會比推遲到下一輪快很多,所以Vue優先將渲染操作推遲到本輪事件循環的最後,如果執行環境不支援會降級到下一輪,Vue的變化偵測機制(setter)決定了它必然會在每次狀態發生變化時都會發出渲染的訊號,但Vue會在收到訊號之後檢查隊列中是否已經存在這個任務,保證隊列中不會有重複,如果隊列中不存在則將渲染操作添加到隊列中,之後通過非同步的方式延遲執行隊列中的所有渲染的操作並清空隊列,當同一輪事件循環中反覆修改狀態時,並不會反覆向隊列中添加相同的渲染操作,所以我們在使用Vue時,修改狀態後更新DOM都是非同步的。
當數據變化後會調用notify方法,將watcher遍歷,調用update方法通知watcher進行更新,這時候watcher並不會立即去執行,在update中會調用queueWatcher方法將watcher放到了一個隊列里,在queueWatcher會根據watcher的進行去重,若多個屬性依賴一個watcher,則如果隊列中沒有該watcher就會將該watcher添加到隊列中,然後便會在$nextTick方法的執行隊列中加入一個flushSchedulerQueue方法(這個方法將會觸發在緩衝隊列的所有回調的執行),然後將$nextTick方法的回調加入$nextTick方法中維護的執行隊列,flushSchedulerQueue中開始會觸發一個before的方法,其實就是beforeUpdate,然後watcher.run()才開始真正執行watcher,執行完頁面就渲染完成,更新完成後會調用updated鉤子。

$nextTick

在上文中談到了對於Vue為何採用非同步渲染,假如此時我們有一個需求,需要在頁面渲染完成後取得頁面的DOM元素,而由於渲染是非同步的,我們不能直接在定義的方法中同步取得這個值的,於是就有了vm.$nextTick方法,Vue$nextTick方法將回調延遲到下次DOM更新循環之後執行,也就是在下次DOM更新循環結束之後執行延遲回調,在修改數據之後立即使用這個方法,能夠獲取更新後的DOM。簡單來說就是當數據更新時,在DOM中渲染完成後,執行回調函數。
通過一個簡單的例子來演示$nextTick方法的作用,首先需要知道Vue在更新DOM時是非同步執行的,也就是說在更新數據時其不會阻塞程式碼的執行,直到執行棧中程式碼執行結束之後,才開始執行非同步任務隊列的程式碼,所以在數據更新時,組件不會立即渲染,此時在獲取到DOM結構後取得的值依然是舊的值,而在$nextTick方法中設定的回調函數會在組件渲染完成之後執行,取得DOM結構後取得的值便是新的值。

<!DOCTYPE html>
<html>
<head>
    <title>Vue</title>
</head>
<body>
    <div id="app"></div>
</body>
<script src="//cdn.bootcss.com/vue/2.4.2/vue.js"></script>
<script type="text/javascript">
    var vm = new Vue({
        el: '#app',
        data: {
            msg: 'Vue'
        },
        template:`
            <div>
                <div ref="msgElement">{{msg}}</div>
                <button @click="updateMsg">updateMsg</button>
            </div>
        `,
        methods:{
            updateMsg: function(){
                this.msg = "Update";
                console.log("DOM未更新:", this.$refs.msgElement.innerHTML)
                this.$nextTick(() => {
                    console.log("DOM已更新:", this.$refs.msgElement.innerHTML)
                })
            }
        },
        
    })
</script>
</html>

非同步機制

官方文檔中說明,Vue在更新DOM時是非同步執行的,只要偵聽到數據變化,Vue將開啟一個隊列,並緩衝在同一事件循環中發生的所有數據變更,如果同一個watcher被多次觸發,只會被推入到隊列中一次。這種在緩衝時去除重複數據對於避免不必要的計算和DOM操作是非常重要的。然後,在下一個的事件循環tick中,Vue刷新隊列並執行實際工作。Vue在內部對非同步隊列嘗試使用原生的Promise.thenMutationObserversetImmediate,如果執行環境不支援,則會採用 setTimeout(fn, 0)代替。
Js是單執行緒的,其引入了同步阻塞與非同步非阻塞的執行模式,在Js非同步模式中維護了一個Event LoopEvent Loop是一個執行模型,在不同的地方有不同的實現,瀏覽器和NodeJS基於不同的技術實現了各自的Event Loop。瀏覽器的Event Loop是在HTML5的規範中明確定義,NodeJSEvent Loop是基於libuv實現的。
在瀏覽器中的Event Loop由執行棧Execution Stack、後台執行緒Background Threads、宏隊列Macrotask Queue、微隊列Microtask Queue組成。

  • 執行棧就是在主執行緒執行同步任務的數據結構,函數調用形成了一個由若干幀組成的棧。
  • 後台執行緒就是瀏覽器實現對於setTimeoutsetIntervalXMLHttpRequest等等的執行執行緒。
  • 宏隊列,一些非同步任務的回調會依次進入宏隊列,等待後續被調用,包括setTimeoutsetIntervalsetImmediate(Node)requestAnimationFrameUI renderingI/O等操作。
  • 微隊列,另一些非同步任務的回調會依次進入微隊列,等待後續調用,包括Promiseprocess.nextTick(Node)Object.observeMutationObserver等操作。

Js執行時,進行如下流程:

  1. 首先將執行棧中程式碼同步執行,將這些程式碼中非同步任務加入後台執行緒中。
  2. 執行棧中的同步程式碼執行完畢後,執行棧清空,並開始掃描微隊列。
  3. 取出微隊列隊首任務,放入執行棧中執行,此時微隊列是進行了出隊操作。
  4. 當執行棧執行完成後,繼續出隊微隊列任務並執行,直到微隊列任務全部執行完畢。
  5. 最後一個微隊列任務出隊並進入執行棧後微隊列中任務為空,當執行棧任務完成後,開始掃面微隊列為空,繼續掃描宏隊列任務,宏隊列出隊,放入執行棧中執行,執行完畢後繼續掃描微隊列為空則掃描宏隊列,出隊執行。
  6. 不斷往複...

實例

// Step 1
console.log(1);

// Step 2
setTimeout(() => {
  console.log(2);
  Promise.resolve().then(() => {
    console.log(3);
  });
}, 0);

// Step 3
new Promise((resolve, reject) => {
  console.log(4);
  resolve();
}).then(() => {
  console.log(5);
})

// Step 4
setTimeout(() => {
  console.log(6);
}, 0);

// Step 5
console.log(7);

// Step N
// ...

// Result
/*
  1
  4
  7
  5
  2
  3
  6
*/
Step 1
// 執行棧 console
// 微隊列 []
// 宏隊列 []
console.log(1); // 1
Step 2
// 執行棧 setTimeout
// 微隊列 []
// 宏隊列 [setTimeout1]
setTimeout(() => {
  console.log(2);
  Promise.resolve().then(() => {
    console.log(3);
  });
}, 0);
Step 3
// 執行棧 Promise
// 微隊列 [then1]
// 宏隊列 [setTimeout1]
new Promise((resolve, reject) => {
  console.log(4); // 4 // Promise是個函數對象,此處是同步執行的 // 執行棧 Promise console
  resolve();
}).then(() => {
  console.log(5);
})
Step 4
// 執行棧 setTimeout
// 微隊列 [then1]
// 宏隊列 [setTimeout1 setTimeout2]
setTimeout(() => {
  console.log(6);
}, 0);
Step 5
// 執行棧 console
// 微隊列 [then1]
// 宏隊列 [setTimeout1 setTimeout2]
console.log(7); // 7
Step 6
// 執行棧 then1
// 微隊列 []
// 宏隊列 [setTimeout1 setTimeout2]
console.log(5); // 5
Step 7
// 執行棧 setTimeout1
// 微隊列 [then2]
// 宏隊列 [setTimeout2]
console.log(2); // 2
Promise.resolve().then(() => {
    console.log(3);
});
Step 8
// 執行棧 then2
// 微隊列 []
// 宏隊列 [setTimeout2]
console.log(3); // 3
Step 9
// 執行棧 setTimeout2
// 微隊列 []
// 宏隊列 []
console.log(6); // 6

分析

在了解非同步任務的執行隊列後,回到中$nextTick方法,當用戶數據更新時,Vue將會維護一個緩衝隊列,對於所有的更新數據將要進行的組件渲染與DOM操作進行一定的策略處理後加入緩衝隊列,然後便會在$nextTick方法的執行隊列中加入一個flushSchedulerQueue方法(這個方法將會觸發在緩衝隊列的所有回調的執行),然後將$nextTick方法的回調加入$nextTick方法中維護的執行隊列,在非同步掛載的執行隊列觸發時就會首先會首先執行flushSchedulerQueue方法來處理DOM渲染的任務,然後再去執行$nextTick方法構建的任務,這樣就可以實現在$nextTick方法中取得已渲染完成的DOM結構。在測試的過程中發現了一個很有意思的現象,在上述例子中的加入兩個按鈕,在點擊updateMsg按鈕的結果是3 2 1,點擊updateMsgTest按鈕的運行結果是2 3 1

<!DOCTYPE html>
<html>
<head>
    <title>Vue</title>
</head>
<body>
    <div id="app"></div>
</body>
<script src="//cdn.bootcss.com/vue/2.4.2/vue.js"></script>
<script type="text/javascript">
    var vm = new Vue({
        el: '#app',
        data: {
            msg: 'Vue'
        },
        template:`
            <div>
                <div ref="msgElement">{{msg}}</div>
                <button @click="updateMsg">updateMsg</button>
                <button @click="updateMsgTest">updateMsgTest</button>
            </div>
        `,
        methods:{
            updateMsg: function(){
                this.msg = "Update";
                setTimeout(() => console.log(1))
                Promise.resolve().then(() => console.log(2))
                this.$nextTick(() => {
                    console.log(3)
                })
            },
            updateMsgTest: function(){
                setTimeout(() => console.log(1))
                Promise.resolve().then(() => console.log(2))
                this.$nextTick(() => {
                    console.log(3)
                })
            }
        },
        
    })
</script>
</html>

這裡假設運行環境中Promise對象是完全支援的,那麼使用setTimeout是宏隊列在最後執行這個是沒有異議的,但是使用$nextTick方法以及自行定義的Promise實例是有執行順序的問題的,雖然都是微隊列任務,但是在Vue中具體實現的原因導致了執行順序可能會有所不同,首先直接看一下$nextTick方法的源碼,關鍵地方添加了注釋,請注意這是Vue2.4.2版本的源碼,在後期$nextTick方法可能有所變更。

/**
 * Defer a task to execute it asynchronously.
 */
var nextTick = (function () {
  // 閉包 內部變數
  var callbacks = []; // 執行隊列
  var pending = false; // 標識,用以判斷在某個事件循環中是否為第一次加入,第一次加入的時候才觸發非同步執行的隊列掛載
  var timerFunc; // 以何種方法執行掛載非同步執行隊列,這裡假設Promise是完全支援的

  function nextTickHandler () { // 非同步掛載的執行任務,觸發時就已經正式準備開始執行非同步任務了
    pending = false; // 標識置false
    var copies = callbacks.slice(0); // 創建副本
    callbacks.length = 0; // 執行隊列置空
    for (var i = 0; i < copies.length; i++) {
      copies[i](); // 執行
    }
  }

  // the nextTick behavior leverages the microtask queue, which can be accessed
  // via either native Promise.then or MutationObserver.
  // MutationObserver has wider support, however it is seriously bugged in
  // UIWebView in iOS >= 9.3.3 when triggered in touch event handlers. It
  // completely stops working after triggering a few times... so, if native
  // Promise is available, we will use it:
  /* istanbul ignore if */
  if (typeof Promise !== 'undefined' && isNative(Promise)) {
    var p = Promise.resolve();
    var logError = function (err) { console.error(err); };
    timerFunc = function () {
      p.then(nextTickHandler).catch(logError); // 掛載非同步任務隊列
      // 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 if (typeof MutationObserver !== 'undefined' && (
    isNative(MutationObserver) ||
    // PhantomJS and iOS 7.x
    MutationObserver.toString() === '[object MutationObserverConstructor]'
  )) {
    // use MutationObserver where native Promise is not available,
    // e.g. PhantomJS IE11, iOS7, Android 4.4
    var counter = 1;
    var observer = new MutationObserver(nextTickHandler);
    var textNode = document.createTextNode(String(counter));
    observer.observe(textNode, {
      characterData: true
    });
    timerFunc = function () {
      counter = (counter + 1) % 2;
      textNode.data = String(counter);
    };
  } else {
    // fallback to setTimeout
    /* istanbul ignore next */
    timerFunc = function () {
      setTimeout(nextTickHandler, 0);
    };
  }

  return function queueNextTick (cb, ctx) { // nextTick方法真正導出的方法
    var _resolve;
    callbacks.push(function () { // 添加到執行隊列中 並加入異常處理
      if (cb) {
        try {
          cb.call(ctx);
        } catch (e) {
          handleError(e, ctx, 'nextTick');
        }
      } else if (_resolve) {
        _resolve(ctx);
      }
    });
    //判斷在當前事件循環中是否為第一次加入,若是第一次加入則置標識為true並執行timerFunc函數用以掛載執行隊列到Promise
    // 這個標識在執行隊列中的任務將要執行時便置為false並創建執行隊列的副本去運行執行隊列中的任務,參見nextTickHandler函數的實現
    // 在當前事件循環中置標識true並掛載,然後再次調用nextTick方法時只是將任務加入到執行隊列中,直到掛載的非同步任務觸發,便置標識為false然後執行任務,再次調用nextTick方法時就是同樣的執行方式然後不斷如此往複
    if (!pending) { 
      pending = true;
      timerFunc();
    }
    if (!cb && typeof Promise !== 'undefined') {
      return new Promise(function (resolve, reject) {
        _resolve = resolve;
      })
    }
  }
})();

回到剛才提出的問題上,在更新DOM操作時會先觸發$nextTick方法的回調,解決這個問題的關鍵在於誰先將非同步任務掛載到Promise對象上。
首先對有數據更新的updateMsg按鈕觸發的方法進行debug,斷點設置在Vue.js715行,版本為2.4.2,在查看調用棧以及傳入的參數時可以觀察到第一次執行$nextTick方法的其實是由於數據更新而調用的nextTick(flushSchedulerQueue);語句,也就是說在執行this.msg = "Update";的時候就已經觸發了第一次的$nextTick方法,此時在$nextTick方法中的任務隊列會首先將flushSchedulerQueue方法加入隊列並掛載$nextTick方法的執行隊列到Promise對象上,然後才是自行自定義的Promise.resolve().then(() => console.log(2))語句的掛載,當執行微任務隊列中的任務時,首先會執行第一個掛載到Promise的任務,此時這個任務是運行執行隊列,這個隊列中有兩個方法,首先會運行flushSchedulerQueue方法去觸發組件的DOM渲染操作,然後再執行console.log(3),然後執行第二個微隊列的任務也就是() => console.log(2),此時微任務隊列清空,然後再去宏任務隊列執行console.log(1)
接下來對於沒有數據更新的updateMsgTest按鈕觸發的方法進行debug,斷點設置在同樣的位置,此時沒有數據更新,那麼第一次觸發$nextTick方法的是自行定義的回調函數,那麼此時$nextTick方法的執行隊列才會被掛載到Promise對象上,很顯然在此之前自行定義的輸出2Promise回調已經被掛載,那麼對於這個按鈕綁定的方法的執行流程便是首先執行console.log(2),然後執行$nextTick方法閉包的執行隊列,此時執行隊列中只有一個回調函數console.log(3),此時微任務隊列清空,然後再去宏任務隊列執行console.log(1)
簡單來說就是誰先掛載Promise對象的問題,在調用$nextTick方法時就會將其閉包內部維護的執行隊列掛載到Promise對象,在數據更新時Vue內部首先就會執行$nextTick方法,之後便將執行隊列掛載到了Promise對象上,其實在明白JsEvent Loop模型後,將數據更新也看做一個$nextTick方法的調用,並且明白$nextTick方法會一次性執行所有推入的回調,就可以明白其執行順序的問題了,下面是一個關於$nextTick方法的最小化的DEMO

var nextTick = (function(){

    var pending = false;
    const callback = [];
    var p = Promise.resolve();

    var handler = function(){
        pending = true;
        callback.forEach(fn => fn());
    }

    var timerFunc = function(){
        p.then(handler);
    }

    return function queueNextTick(fn){
        callback.push(() => fn());
        if(!pending){
            pending = true;
            timerFunc();
        }
    }

})();


(function(){
    nextTick(() => console.log("觸發DOM渲染隊列的方法")); // 注釋 / 取消注釋 來查看效果
    setTimeout(() => console.log(1))
    Promise.resolve().then(() => console.log(2))
    nextTick(() => {
        console.log(3)
    })
})();

每日一題

//github.com/WindrunnerMax/EveryDay

參考

//zhuanlan.zhihu.com/p/29631893
//github.com/berwin/Blog/issues/22
//juejin.cn/post/6899822303022956552
//segmentfault.com/a/1190000015698196
//cn.vuejs.org/v2/guide/reactivity.html
//blog.csdn.net/weixin_46396187/article/details/107462329
Tags: