別眨眼網

`，  components： { Item }，  data（） {    return {      list： ［        { id： ‘a’， color： ‘#f00’， message： ‘a’ }，        { id： ‘b’， color： ‘#0f0’， message： ‘b’ }      ］    }  }，  methods： {    reverse（） {      this。list。reverse（）    }  }}）。$mount（‘#app’）複製程式碼

這裡有一個 list，會渲染出來

a b

，點選後會執行

reverse

方法將這個 list 顛倒下順序，你可以將這個例子複製下來，在自己的電腦上看下效果。

我們先來分析用

id

作為 key 時，點選時會發生什麼，

由於 list 發生了改變，會觸發

Parent

元件的重新渲染，拿到新的

vnode

，和舊的

vnode

去執行

patch

，我們主要關心的就是

patch

過程中的

updateChildren

邏輯，

updateChildren

就是對新舊兩個

children

執行

diff

演算法，使盡可能地對節點進行復用，對於我們這個例子而言，此時

舊的children

是：

；［  {    tag： ‘Item’，    key： ‘a’，    propsData： {      color： ‘#f00’，      message： ‘紅色’    }  }，  {    tag： ‘Item’，    key： ‘b’，    propsData： {      color： ‘#0f0’，      message： ‘綠色’    }  }］複製程式碼

執行

reverse

後的

新的children

是：

；［  {    tag： ‘Item’，    key： ‘b’，    propsData： {      color： ‘#0f0’，      message： ‘綠色’    }  }，  {    tag： ‘Item’，    key： ‘a’，    propsData： {      color： ‘#f00’，      message： ‘紅色’    }  }］複製程式碼

此時執行

updateChildren

，

updateChildren

會對新舊兩組 children 節點的迴圈進行對比：

while （oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx） {  if （isUndef（oldStartVnode）） {    oldStartVnode = oldCh［++oldStartIdx］ // Vnode has been moved left  } else if （isUndef（oldEndVnode）） {    oldEndVnode = oldCh［——oldEndIdx］  } else if （sameVnode（oldStartVnode， newStartVnode）） {    // 對新舊節點執行patchVnode    // 移動指標  } else if （sameVnode（oldEndVnode， newEndVnode）） {    // 對新舊節點執行patchVnode    // 移動指標  } else if （sameVnode（oldStartVnode， newEndVnode）） {    // 對新舊節點執行patchVnode    // 移動oldStartVnode節點    // 移動指標  } else if （sameVnode（oldEndVnode， newStartVnode）） {    // 對新舊節點執行patchVnode    // 移動oldEndVnode節點    // 移動指標  } else {    //。。。  }}複製程式碼

透過

sameVnode

判斷兩個節點是相同節點的話，就會執行相應的邏輯：

function sameVnode（a， b） {  return （    a。key === b。key &&    （（a。tag === b。tag &&      a。isComment === b。isComment &&      isDef（a。data） === isDef（b。data） &&      sameInputType（a， b）） ||      （isTrue（a。isAsyncPlaceholder） &&        a。asyncFactory === b。asyncFactory &&        isUndef（b。asyncFactory。error）））  ）}複製程式碼

sameVnode

主要就是透過 key 去判斷，由於我們顛倒了 list 的順序，所以第一輪對比中：

sameVnode（oldStartVnode， newEndVnode）

成立，即舊的首節點和新的尾節點是同一個節點，此時會執行

patchVnode

邏輯，

patchVnode

中會執行

prePatch

，

prePatch

中會更新 props，此時我們的兩個節點的

propsData

是相同的，都為

{color： ‘#0f0’，message： ‘綠色’}

，這樣的話

Item

元件的 props 就不會更新，

Item

也不會重新渲染。再回到

updateChildren

中，會繼續執行

“移動oldStartVnode節點”

的操作，將 DOM 元素。移動到正確位置，其他節點對比也是同樣的流程。

可以發現，在整個流程中，

只是移動了節點，並沒有觸發 Item 元件的重新渲染

，這樣實現了節點的複用。

我們再來看下使用

index

作為 key 的情況，使用

index

時，

舊的children

是：

；［  {    tag： ‘Item’，    key： 0，    propsData： {      color： ‘#f00’，      message： ‘紅色’    }  }，  {    tag： ‘Item’，    key： 1，    propsData： {      color： ‘#0f0’，      message： ‘綠色’    }  }］複製程式碼

執行

reverse

後的

新的children

是：

；［  {    tag： ‘Item’，    key： 0，    propsData： {      color： ‘#0f0’，      message： ‘綠色’    }  }，  {    tag： ‘Item’，    key： 1，    propsData： {      color： ‘#f00’，      message： ‘紅色’    }  }］複製程式碼

這裡和

id

作為 key 時的節點就有所不同了，雖然我們把 list 順序顛倒了，但是 key 的順序卻沒變，在

updateChildren

時

sameVnode（oldStartVnode， newStartVnode）

將會成立，即舊的首節點和新的首節點相同，此時執行

patchVnode -> prePatch -> 更新props

，這個時候舊的 propsData 是

{color： ‘#f00’，message： ‘紅色’}

，新的 propsData 是

{color： ‘#0f0’，message： ‘綠色’}

，更新過後，Item 的 props 將會發生改變，

會觸發 Item 元件的重新渲染

。

這就是 index 作為 key 和 id 作為 key 時的區別，

id 作為 key 時，僅僅是移動了節點，並沒有觸發 Item 的重新渲染。index 作為 key 時，觸發了 Item 的重新渲染

，可想而知，當 Item 是一個複雜的元件時，必然會引起效能問題。

上面的流程比較複雜，涉及的也比較多，可以拆開寫好幾篇文章，有些地方我只是簡略的說了一下，如果你不是很明白的話，你可以把上面的例子複製下來，在自己的電腦上調式，我在 Item 的渲染函式中加了列印日誌和 debugger，你可以分別用 id 和 index 作為 key 嘗試下，你會發現 id 作為 key 時，Item 的渲染函式沒有執行，但是 index 作為 key 時，Item 的渲染函式執行了，這就是這兩種方式的區別。

延遲渲染

延遲渲染就是分批渲染，假設我們某個頁面裡有一些元件在初始化時需要執行復雜的邏輯：

複製程式碼

這將會佔用很長時間，導致幀數下降、卡頓，其實可以使用分批渲染的方式來進行最佳化，就是先渲染一部分，再渲染另一部分：

參考黃軼老師揭秘 Vue。js 九個效能最佳化技巧中的程式碼：

複製程式碼

其實原理很簡單，主要是維護

displayPriority

變數，透過

requestAnimationFrame

在每一幀渲染時自增，然後我們就可以在元件上透過

v-if=“defer（n）”

使

displayPriority

增加到某一值時再渲染，這樣就可以避免 js 執行時間過長導致的卡頓問題了。

使用非響應式資料

在 Vue 元件初始化資料時，會遞迴遍歷在 data 中定義的每一條資料，透過

Object。defineProperty

將資料改成響應式，這就意味著如果 data 中的資料量很大的話，在初始化時將會使用很長的時間去執行

Object。defineProperty

， 也就會帶來效能問題，這個時候我們可以強制使資料變為非響應式，從而節省時間，看下這個例子：

複製程式碼

heavyData

中有一萬條資料，這裡統計了下從

beforeCreate

到

created

經歷的時間，對於這個例子而言，這個時間基本上就是初始化資料的時間。

我在我個人的電腦上多次測試，這個時間一直在

40-50ms

，然後我們透過

Object。freeze（）

方法，將

heavyData

變為非響應式的再試下：

//。。。data（） {  return {    heavyData： Object。freeze（heavyData）  }}//。。。複製程式碼

改完之後再試下，初始化資料的時間變成了

0-1ms

，快了有

40ms

，這

40ms

都是遞迴遍歷

heavyData

執行

Object。defineProperty

的時間。

那麼，為什麼

Object。freeze（）

會有這樣的效果呢？對某一物件使用

Object。freeze（）

後，將不能向這個物件新增新的屬性，不能刪除已有屬性，不能修改該物件已有屬性的可列舉性、可配置性、可寫性，以及不能修改已有屬性的值。

而 Vue 在將資料改造成響應式之前有個判斷：

export function observe（value， asRootData） {  // 。。。省略其他邏輯  if （    shouldObserve &&    ！isServerRendering（） &&    （Array。isArray（value） || isPlainObject（value）） &&    Object。isExtensible（value） &&    ！value。_isVue  ） {    ob = new Observer（value）  }  // 。。。省略其他邏輯}複製程式碼

這個判斷條件中有一個

Object。isExtensible（value）

，這個方法是判斷一個物件是否是可擴充套件的，由於我們使用了

Object。freeze（）

，這裡肯定就返回了

false

，所以就跳過了下面的過程，自然就省了很多時間。

實際上，不止初始化資料時有影響，你可以用上面的例子統計下從

created

到

mounted

所用的時間，在我的電腦上不使用

Object。freeze（）

時，這個時間是

60-70ms

，使用

Object。freeze（）

後降到了

40-50ms

，這是因為在渲染函式中讀取

heavyData

中的資料時，會執行到透過

Object。defineProperty

定義的

getter

方法，Vue 在這裡做了一些收集依賴的處理，肯定就會佔用一些時間，由於使用了

Object。freeze（）

後的資料是非響應式的，沒有了收集依賴的過程，自然也就節省了效能。

由於訪問響應式資料會走到自定義 getter 中並收集依賴，所以平時使用時要避免頻繁訪問響應式資料，比如在遍歷之前先將這個資料存在區域性變數中，尤其是在計算屬性、渲染函式中使用，關於這一點更具體的說明，你可以看黃奕老師的這篇文章：Local variables

但是這樣做也不是沒有任何問題的，這樣會導致

heavyData

下的資料都不是響應式資料，你對這些資料使用

computed

、

watch

等都不會產生效果，不過通常來說這種大量的資料都是展示用的，如果你有特殊的需求，你可以只對這種資料的某一層使用

Object。freeze（）

，同時配合使用上文中的延遲渲染、函式式元件等，可以極大提升效能。

模板編譯和渲染函式、JSX 的效能差異

Vue 專案不僅可以使用 SFC 的方式開發，也可以使用渲染函式或 JSX 開發，很多人認為僅僅是隻是開發方式不同，卻不知這些開發方式之間也有效能差異，甚至差異很大，這一節我就找些例子來說明下，希望你以後在選擇開發方式時有更多衡量的標準。

其實 Vue2 模板編譯中的效能最佳化不多，Vue3 中有很多，Vue3 透過編譯和執行時結合的方式提升了很大的效能，但是由於本篇文章講的是 Vue2 的效能最佳化，並且 Vue2 現在還是有很多人在使用，所以我就挑 Vue2 模板編譯中的一點來說下。

靜態節點

下面這個模板：

複製程式碼

會被編譯成：

function render（） {  with （this） {    return _m（0）  }}複製程式碼

可以看到和普通的渲染函式是有些不一樣的，下面我們來看下為什麼會編譯成這樣的程式碼。

Vue 的編譯會經過

optimize

過程，這個過程中會標記靜態節點，具體內容可以看黃奕老師寫的這個文件：Vue2 編譯 - optimize 標記靜態節點。

在

codegen

階段判斷到靜態節點的標記會走到

genStatic

的分支：

function genStatic（el， state） {  el。staticProcessed = true  const originalPreState = state。pre  if （el。pre） {    state。pre = el。pre  }  state。staticRenderFns。push（`with（this）{return ${genElement（el， state）}}`）  state。pre = originalPreState  return `_m（${state。staticRenderFns。length - 1}${    el。staticInFor ？ ‘，true’ ： ‘’  }）`}複製程式碼

這裡就是生成程式碼的關鍵邏輯，這裡會把渲染函式儲存在

staticRenderFns

裡，然後拿到當前值的下標生成

_m

函式，這就是為什麼我們會得到

_m（0）

。

這個

_m

其實是

renderStatic

的縮寫：

export function renderStatic（index， isInFor） {  const cached = this。_staticTrees || （this。_staticTrees = ［］）  let tree = cached［index］  if （tree && ！isInFor） {    return tree  }  tree = cached［index］ = this。$options。staticRenderFns［index］。call（    this。_renderProxy，    null，    this  ）  markStatic（tree， `__static__${index}`， false）  return tree}function markStatic（tree， key） {  if （Array。isArray（tree）） {    for （let i = 0； i < tree。length； i++） {      if （tree［i］ && typeof tree［i］ ！== ‘string’） {        markStaticNode（tree［i］， `${key}_${i}`， isOnce）      }    }  } else {    markStaticNode（tree， key， isOnce）  }}function markStaticNode（node， key， isOnce） {  node。isStatic = true  node。key = key  node。isOnce = isOnce}複製程式碼

renderStatic

的內部實現比較簡單，先是獲取到元件例項的

_staticTrees

，如果沒有就建立一個，然後嘗試從

_staticTrees

上獲取之前快取的節點，獲取到的話就直接返回，否則就從

staticRenderFns

上獲取到對應的渲染函式執行並將結果快取到

_staticTrees

上，這樣下次再進入這個函式時就會直接從快取上返回結果。

拿到節點後還會透過

markStatic

將節點打上

isStatic

等標記，標記為

isStatic

的節點會直接跳過

patchVnode

階段，因為靜態節點是不會變的，所以也沒必要 patch，跳過 patch 可以節省效能。

透過編譯和執行時結合的方式，可以幫助我們很好的提升應用效能，這是渲染函式 / JSX 很難達到的，當然不是說不能用 JSX，相比於模板，JSX 更加靈活，兩者有各自的使用場景。在這裡寫這些是希望能給你提供一些技術選型的標準。

Vue2 的編譯最佳化除了靜態節點，還有插槽，createElement 等。

Vue3 的模板編譯最佳化

相比於 Vue2，Vue3 中的模板編譯最佳化更加突出，效能提升的更多，由於涉及的比較多，本篇文章寫不下，如果你感興趣的話你可以看看這些文章：Vue3 Compiler 最佳化細節，如何手寫高效能渲染函式，聊聊 Vue。js 3。0 的模板編譯最佳化，以及尤雨溪的解讀影片：Vue 之父尤雨溪深度解讀 Vue3。0 的開發思路，以後我也會單獨寫一些文章分析 Vue3 的模板編譯最佳化。