導語 最近碰到部分業務場景，代碼邏輯需要了解"數組變更后，具體變更了哪一些元素，以及變更的位置.."。于是仔細研究并覆寫了一遍針對數組變化的diff算法，在這里做下diff算法的邏輯分享&&源碼解讀

一.介紹前的準備工作

我們先了解diff方法的運行規則和前提方法.

1.虛擬node進行深度優先 && 同級對比

深度優先:

同級對比

如上面圖所示：

每次vnode都是執行同級對比(對應dom同一個父元素)

代碼邏輯如下圖：

2.簡單判斷

sameVnode函數用來進行判斷是否是同一個vnode元素。

源代碼：

如圖所示：

這里有兩個重要元素：

key : 開發者定義的”:key”

sel: 元素tagName+元素id+元素class

sel的定義源碼如下：

vNode構建函數：

3.構建索引

邏輯如圖：

二.如何處理元素

盡量不新增/刪除dom，如圖下所示:

如果是相同vnode，源碼如下：

三.開始比較

1.首先會進行時間復雜度 O(n)的while循環，循環條件為 "遍歷舊節點數組&&遍歷新節點數組，誰先遍歷完循環就結束" ，源碼如下圖:

在每次的循環過程中，會有兩大類判斷方法：

1-1.首尾比較 && 首尾序號

邏輯：如圖上所示，首先在循環遍歷前 標記好新，舊節點數組的開始位置和結束位置的序號：oldStartIdx、oldEndIdx、newStartIdx、newEndIdx；其次在循環遍歷的過程中采用 "首首比較，尾尾比較，首尾比較"；

源碼如下：

如果數據為圖上所示，那么根據首尾比較方法會有如下圖所示結果，最終全部執行了更新操作：

1-2.索引比較 -- 最壞情況,這里的時間復雜度也是O(n)，即整個算法復雜度O(n)+O(n)

每次遍歷的過程中可能存在"新數組節點新增/舊數組節點刪除"，那么前后對比就滿足不了條件。這里邏輯會進入索引比較;

比如這種情況：

那么，循環中會執行一遍 創建舊數組的索引對象。

那么從創建到比較的整個邏輯圖如下：

這里的源碼如下:

1-2.1 當舊節點不存在新增的節點時,進行當前oldStartIdx位置的添加:

源碼如下:

1-2.2 當舊數組存在節點，那么進行位置移動:

源碼：

1.3 當節點遍歷完之后：

會存在兩種情況，“新數組已經遍歷完，但舊數組沒有遍歷完成” || “舊數組遍歷完成，但新數組沒有遍歷完成”.

故源代碼的判斷如下:

1.3.1 舊數組沒有循環完成：

舊數組沒有循環完成的效果如下圖所示：

這里注意一個點，我們每次的節點更新會移動序號，即使被刪除的節點不在一塊 最終也會被 首尾比較算法 "摞在一塊" 即 (oldStartIdx~oldEndIdx)。上圖所示更加明顯一些。

源碼在這里就進行批量刪除：

1.3.2 新數組沒有循環完成:

效果如下圖所示:

經過 前后對比&&索引 的過濾后，只會存在 新.末尾節點!==舊節點 及之前的連續的新節點(!==舊節點);

所以這里也被 "摞在一塊" ，即 (newStartIdx~newEndIdx)

源碼如下：

這樣，整個diff的對比算法就已經走完了。所以核心就是：前后對比+索引

四.關鍵點

關鍵點大概如下

五.vue3.0對于diff比較前的優化

vue3.0針對"無腦"patchVnode進行了過濾 -- 靜態類型Vnode：

老版的源碼:

這里，我們再重復下vue2.x系列的對比更新邏輯:

新版的vue3.0增加了 靜態類型Vnode，如果是靜態類型的vnode 那么直接跳過更新，修改新節點引用即可:

備注:comment類型 目前翻到它的源碼也只是更改引用，源碼作者加上了一行注釋：

這里再多插一句，fragment 碎片類型 為新增的vnode類型， 即：

vue3.0的過濾判斷源碼如下:

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的diff算法_vue源码解读 diff算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。