解析vue2.0的diff演算法

虛光發表於2017-12-27

目錄

  • 前言
  • virtual dom
  • 分析diff
  • 總結

前言

vue2.0加入了virtual dom,有向react靠攏的意思。vue的diff位於patch.js檔案中,我的一個小框架aoy也同樣使用此演算法,該演算法來源於snabbdom,複雜度為O(n)。
瞭解diff過程可以讓我們更高效的使用框架。
本文力求以圖文並茂的方式來講明這個diff的過程。

virtual dom

如果不瞭解virtual dom,要理解diff的過程是比較困難的。虛擬dom對應的是真實dom, 使用document.CreateElementdocument.CreateTextNode建立的就是真實節點。

我們可以做個試驗。列印出一個空元素的第一層屬性,可以看到標準讓元素實現的東西太多了。如果每次都重新生成新的元素,對效能是巨大的浪費。

virtual dom就是解決這個問題的一個思路,到底什麼是virtual dom呢?通俗易懂的來說就是用一個簡單的物件去代替複雜的dom物件。舉個簡單的例子,我們在body裡插入一個class為a的div。

對於這個div我們可以用一個簡單的物件mydivVirtual代表它,它儲存了對應dom的一些重要引數,在改變dom之前,會先比較相應虛擬dom的資料,如果需要改變,才會將改變應用到真實dom上。

讀到這裡就會產生一個疑問,為什麼不直接修改dom而需要加一層virtual dom呢?

很多時候手工優化dom確實會比virtual dom效率高,對於比較簡單的dom結構用手工優化沒有問題,但當頁面結構很龐大,結構很複雜時,手工優化會花去大量時間,而且可維護性也不高,不能保證每個人都有手工優化的能力。至此,virtual dom的解決方案應運而生,virtual dom很多時候都不是最優的操作,但它具有普適性,在效率、可維護性之間達平衡。

virtual dom 另一個重大意義就是提供一箇中間層,js去寫ui,ios安卓之類的負責渲染,就像reactNative一樣。

分析diff

一篇相當經典的文章React’s diff algorithm中的圖,react的diff其實和vue的diff大同小異。所以這張圖能很好的解釋過程。比較只會在同層級進行, 不會跨層級比較。

1286899590-56d41b839c27f_articlex

舉個形象的例子。

我們可能期望將<span>直接移動到<p>的後邊,這是最優的操作。但是實際的diff操作是移除<p>裡的<span>在建立一個新的<span>插到<p>的後邊。
因為新加的<span>在層級2,舊的在層級3,屬於不同層級的比較。

原始碼分析

文中的程式碼位於aoy-diff中,已經精簡了很多程式碼,留下最核心的部分。

diff的過程就是呼叫patch函式,就像打補丁一樣修改真實dom。

patch函式有兩個引數,vnodeoldVnode,也就是新舊兩個虛擬節點。在這之前,我們先了解完整的vnode都有什麼屬性,舉個一個簡單的例子:

需要注意的是,el屬性引用的是此 virtual dom對應的真實dom,patchvnode引數的el最初是null,因為patch之前它還沒有對應的真實dom。

來到patch的第一部分,

sameVnode函式就是看這兩個節點是否值得比較,程式碼相當簡單:

兩個vnode的key和sel相同才去比較它們,比如pspandiv.classAdiv.classB都被認為是不同結構而不去比較它們。

如果值得比較會執行patchVnode(oldVnode, vnode),稍後會詳細講patchVnode函式。

當節點不值得比較,進入else中

過程如下:

  • 取得oldvnode.el的父節點,parentEle是真實dom
  • createEle(vnode)會為vnode建立它的真實dom,令vnode.el =真實dom
  • parentEle將新的dom插入,移除舊的dom
    當不值得比較時,新節點直接把老節點整個替換了

最後

patch最後會返回vnode,vnode和進入patch之前的不同在哪?
沒錯,就是vnode.el,唯一的改變就是之前vnode.el = null, 而現在它引用的是對應的真實dom。

至此完成一個patch過程。

patchVnode

兩個節點值得比較時,會呼叫patchVnode函式

const el = vnode.el = oldVnode.el 這是很重要的一步,讓vnode.el引用到現在的真實dom,當el修改時,vnode.el會同步變化。

節點的比較有5種情況

  1. if (oldVnode === vnode),他們的引用一致,可以認為沒有變化。
  2. if(oldVnode.text !== null && vnode.text !== null && oldVnode.text !== vnode.text),文字節點的比較,需要修改,則會呼叫Node.textContent = vnode.text
  3. if( oldCh && ch && oldCh !== ch ), 兩個節點都有子節點,而且它們不一樣,這樣我們會呼叫updateChildren函式比較子節點,這是diff的核心,後邊會講到。
  4. else if (ch),只有新的節點有子節點,呼叫createEle(vnode)vnode.el已經引用了老的dom節點,createEle函式會在老dom節點上新增子節點。
  5. else if (oldCh),新節點沒有子節點,老節點有子節點,直接刪除老節點。

updateChildren

程式碼很密集,為了形象的描述這個過程,可以看看這張圖。

3332891351-58d13c20889f8_articlex

過程可以概括為:oldChnewCh各有兩個頭尾的變數StartIdxEndIdx,它們的2個變數相互比較,一共有4種比較方式。如果4種比較都沒匹配,如果設定了key,就會用key進行比較,在比較的過程中,變數會往中間靠,一旦StartIdx>EndIdx表明oldChnewCh至少有一個已經遍歷完了,就會結束比較。

具體的diff分析

設定key和不設定key的區別:
不設key,newCh和oldCh只會進行頭尾兩端的相互比較,設key後,除了頭尾兩端的比較外,還會從用key生成的物件oldKeyToIdx中查詢匹配的節點,所以為節點設定key可以更高效的利用dom。

diff的遍歷過程中,只要是對dom進行的操作都呼叫api.insertBeforeapi.insertBefore只是原生insertBefore的簡單封裝。
比較分為兩種,一種是有vnode.key的,一種是沒有的。但這兩種比較對真實dom的操作是一致的。

對於與sameVnode(oldStartVnode, newStartVnode)sameVnode(oldEndVnode,newEndVnode)為true的情況,不需要對dom進行移動。

總結遍歷過程,有3種dom操作:

  1. oldStartVnodenewEndVnode值得比較,說明oldStartVnode.el跑到oldEndVnode.el的後邊了。

圖中假設startIdx遍歷到1。

2499183708-58d13c70c142d_articlex

  1. oldEndVnodenewStartVnode值得比較,說明 oldEndVnode.el跑到了newStartVnode.el的前邊。

3398278090-58d13c9170466_articlex

  1. newCh中的節點oldCh裡沒有, 將新節點插入到oldStartVnode.el的前邊。

3955293545-58d13ca6a2af2_articlex

在結束時,分為兩種情況:

  1. oldStartIdx > oldEndIdx,可以認為oldCh先遍歷完。當然也有可能newCh此時也正好完成了遍歷,統一都歸為此類。此時newStartIdxnewEndIdx之間的vnode是新增的,呼叫addVnodes,把他們全部插進before的後邊,before很多時候是為null的。addVnodes呼叫的是insertBefore操作dom節點,我們看看insertBefore的文件:parentElement.insertBefore(newElement, referenceElement)
    如果referenceElement為null則newElement將被插入到子節點的末尾。如果newElement已經在DOM樹中,newElement首先會從DOM樹中移除。所以before為null,newElement將被插入到子節點的末尾。

3696513119-58d13cbfab514_articlex

  1. newStartIdx > newEndIdx,可以認為newCh先遍歷完。此時oldStartIdxoldEndIdx之間的vnode在新的子節點裡已經不存在了,呼叫removeVnodes將它們從dom裡刪除。

1324477134-58d13cd1748dc_articlex

下面舉個例子,畫出diff完整的過程,每一步dom的變化都用不同顏色的線標出。

  1. a,b,c,d,e假設是4個不同的元素,我們沒有設定key時,b沒有複用,而是直接建立新的,刪除舊的。

3223069571-58d13ce3cd8e8_articlex

  1. 當我們給4個元素加上唯一key時,b得到了的複用。

1409185203-58d13cfe5e617_articlex

這個例子如果我們使用手工優化,只需要3步就可以達到。

總結

  • 儘量不要跨層級的修改dom
  • 設定key可以最大化的利用節點
  • 不要盲目相信diff的效率,在必要時可以手工優化

相關文章