React中diff演算法的理解

React中diff演算法的理解

diff演算法用來計算出Virtual DOM中改變的部分，然後針對該部分進行DOM操作，而不用重新渲染整個頁面，渲染整個DOM結構的過程中開銷是很大的，需要瀏覽器對DOM結構進行重繪與迴流，而diff演算法能夠使得操作過程中只更新修改的那部分DOM結構而不更新整個DOM，這樣能夠最小化操作DOM結構，能夠最大程度上減少瀏覽器重繪與迴流的規模。

虛擬DOM

diff演算法的基礎是Virtual DOM，Virtual DOM是一棵以JavaScript物件作為基礎的樹，在React中通常是通過JSX編譯而成的，每一個節點稱為VNode，用物件屬性來描述節點，實際上它是一層對真實DOM的抽象，最終可以通過渲染操作使這棵樹對映到真實環境上，簡單來說Virtual DOM就是一個Js物件，用以描述整個文件。
在瀏覽器中構建頁面時需要使用DOM節點描述整個文件。

<div class="root" name="root">
    <p>1</p>
    <div>11</div>
</div>

如果使用Js物件去描述上述的節點以及文件，那麼便類似於下面的樣子，當然這不是React中用以描述節點的物件，React中建立一個React元素的相關原始碼在react/src/ReactElement.js中，文中的React版本是16.10.2。

{
    type: "div",
    props: {
        className: "root"
        name: "root",
        children: [{
            type: "p",
            props: {
                children: [{
                    type: "text",
                    props: {
                        text: "1"
                    }
                    
                }]
            }    
        },{
            type: "div",
            props: {
                children: [{
                    type: "text",
                    props: {
                        text: "11"
                    }
                }]
            }
        }]
    }
}

實際上在React16中啟用了全新的架構Fiber，Fiber核心是實現了一個基於優先順序和requestIdleCallback的迴圈任務排程演算法，相關問題不在文章中討論，相關的問題大致在於虛擬DOM由樹結構轉變成連結串列結構，原來的VDOM是一顆由上至下的樹，通過深度優先遍歷，層層遞迴直下，然而這個深度優先遍歷最大的毛病在於不可中斷，因此我們在diff + patch又或者是Mount巨大節點的時候，會造成較大的卡頓，React16的VDOM不再是一顆由上至下那麼簡單的樹，而是連結串列形式的虛擬DOM，連結串列的每一個節點是Fiber，而不是在16之前的虛擬DOM節點，每個Fiber節點記錄著諸多資訊，以便走到某個節點的時候中斷，Fiber的思路是把渲染/更新過程(遞迴diff)拆分成一系列小任務，每次檢查樹上的一小部分，做完看是否還有時間繼續下一個任務，有的話繼續，沒有的話把自己掛起，主執行緒不忙的時候再繼續。Fiber在diff階段，做了如下的操作，實際相當於在15的diff演算法階段，做了優先順序的任務排程控制。

• 把可中斷的工作拆分成小任務。
• 對正在做的工作調整優先次序、重做、複用上次(未完成)工作。
• diff階段任務排程優先順序控制。

操作虛擬DOM與操作原生DOM的比較

在這裡直接引用了尤大的話(2016-02-08年的回答，此時Vue2.0還未釋出，Vue2.0於2016-10-01左右釋出，Vue2.0才加入虛擬DOM)，相關連結為https://www.zhihu.com/question/31809713，建議結合連結中的問題閱讀，也可以看看問題中比較的示例，另外下面的回答也都非常的精髓。

原生 DOM 操作 vs 通過框架封裝操作

這是一個效能vs可維護性的取捨，框架的意義在於為你掩蓋底層的DOM操作，讓你用更宣告式的方式來描述你的目的，從而讓你的程式碼更容易維護，沒有任何框架可以比純手動的優化DOM操作更快，因為框架的DOM操作層需要應對任何上層API可能產生的操作，它的實現必須是普適的，針對任何一個benchmark，我都可以寫出比任何框架更快的手動優化，但是那有什麼意義呢?在構建一個實際應用的時候，你難道為每一個地方都去做手動優化嗎?出於可維護性的考慮，這顯然不可能，框架給你的保證是，你在不需要手動優化的情況下，我依然可以給你提供過得去的效能。

對 React 的 Virtual DOM 的誤解

React從來沒有說過React比原生操作DOM快，React的基本思維模式是每次有變動就整個重新渲染整個應用，如果沒有Virtual DOM，簡單來想就是直接重置innerHTML，很多人都沒有意識到，在一個大型列表所有資料都變了的情況下，重置innerHTML其實是一個還算合理的操作，真正的問題是在全部重新渲染的思維模式下，即使只有一行資料變了，它也需要重置整個innerHTML，這時候顯然就有大量的浪費。
我們可以比較一下innerHTML vs Virtual DOM的重繪效能消耗：

• innerHTML: render html string O(template size) + 重新建立所有DOM元素O(DOM size)
• Virtual DOM: render Virtual DOM + diff O(template size) + 必要的DOM更新O(DOM change)。

Virtual DOM render + diff顯然比渲染html字串要慢，但是!它依然是純js層面的計算，比起後面的DOM操作來說，依然便宜了太多，可以看到，innerHTML的總計算量不管是js計算還是DOM操作都是和整個介面的大小相關，但Virtual DOM的計算量裡面，只有js計算和介面大小相關，DOM操作是和資料的變動量相關的，前面說了，和DOM操作比起來，js計算是極其便宜的，這才是為什麼要有Virtual DOM:它保證了 1)不管你的資料變化多少，每次重繪的效能都可以接受; 2)你依然可以用類似innerHTML的思路去寫你的應用。

MVVM vs Virtual DOM

相比起React，其他MVVM系框架比如Angular, Knockout以及Vue、Avalon採用的都是資料繫結:通過Directive/Binding物件，觀察資料變化並保留對實際DOM元素的引用，當有資料變化時進行對應的操作，MVVM的變化檢查是資料層面的，而React的檢查是DOM結構層面的，MVVM的效能也根據變動檢測的實現原理有所不同: Angular的髒檢查使得任何變動都有固定的O(watcher count)的代價; Knockout/Vue/Avalon都採用了依賴收集，在js和DOM層面都是O(change):

• 髒檢查：scope digest O(watcher count) + 必要DOM更新O(DOM change)。
• 依賴收集：重新收集依賴O(data change) + 必要DOM更新 O(DOM change)。

可以看到，Angular最不效率的地方在於任何小變動都有的和watcher數量相關的效能代價，但是!當所有資料都變了的時候，Angular其實並不吃虧，依賴收集在初始化和資料變化的時候都需要重新收集依賴，這個代價在小量更新的時候幾乎可以忽略，但在資料量龐大的時候也會產生一定的消耗。
MVVM渲染列表的時候，由於每一行都有自己的資料作用域，所以通常都是每一行有一個對應的ViewModel例項，或者是一個稍微輕量一些的利用原型繼承的scope物件，但也有一定的代價，所以MVVM列表渲染的初始化幾乎一定比React慢，因為建立ViewModel / scope例項比起Virtual DOM來說要昂貴很多，這裡所有MVVM實現的一個共同問題就是在列表渲染的資料來源變動時，尤其是當資料是全新的物件時，如何有效地複用已經建立的ViewModel例項和DOM元素，假如沒有任何複用方面的優化，由於資料是全新的，MVVM實際上需要銷燬之前的所有例項，重新建立所有例項，最後再進行一次渲染!這就是為什麼題目裡連結的angular/knockout實現都相對比較慢，相比之下，React的變動檢查由於是DOM結構層面的，即使是全新的資料，只要最後渲染結果沒變，那麼就不需要做無用功。
順道說一句，React渲染列表的時候也需要提供key這個特殊prop，本質上和track-by是一回事。

效能比較也要看場合

在比較效能的時候，要分清楚初始渲染、小量資料更新、大量資料更新這些不同的場合，Virtual DOM、髒檢查MVVM、資料收集MVVM在不同場合各有不同的表現和不同的優化需求，Virtual DOM為了提升小量資料更新時的效能，也需要針對性的優化，比如shouldComponentUpdate或是immutable data。

• 初始渲染：Virtual DOM > 髒檢查 >= 依賴收集。
• 小量資料更新：依賴收集 >> Virtual DOM + 優化 > 髒檢查(無法優化) > Virtual DOM無優化。
• 大量資料更新：髒檢查 + 優化 >= 依賴收集 + 優化 > Virtual DOM(無法/無需優化) >> MVVM無優化。

不要天真地以為Virtual DOM就是快，diff不是免費的，batching麼MVVM也能做，而且最終patch的時候還不是要用原生API，在我看來Virtual DOM真正的價值從來都不是效能，而是它 1)為函式式的UI程式設計方式開啟了大門; 2)可以渲染到DOM以外的backend，比如ReactNative。

總結

以上這些比較，更多的是對於框架開發研究者提供一些參考，主流的框架+合理的優化，足以應對絕大部分應用的效能需求，如果是對效能有極致需求的特殊情況，其實應該犧牲一些可維護性採取手動優化:比如Atom編輯器在檔案渲染的實現上放棄了React而採用了自己實現的tile-based rendering; 又比如在移動端需要DOM-pooling的虛擬滾動，不需要考慮順序變化，可以繞過框架的內建實現自己搞一個。

diff演算法

React在記憶體中維護一顆虛擬DOM樹，當資料發生改變時(state & props)，會自動的更新虛擬DOM，獲得一個新的虛擬DOM樹，然後通過Diff演算法，比較新舊虛擬DOM樹，找出最小的有變化的部分，將這個變化的部分Patch加入佇列，最終批量的更新這些Patch到實際的DOM中。

時間複雜度

首先進行一次完整的diff需要O(n^3)的時間複雜度，這是一個最小編輯距離的問題，在比較字串的最小編輯距離時使用動態規劃的方案需要的時間複雜度是O(mn)，但是對於DOM來說是一個樹形結構，而樹形結構的最小編輯距離問題的時間複雜度在30多年的演進中從O(m^3n^3)演進到了O(n^3)，關於這個問題如果有興趣的話可以研究一下論文https://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf。
對於原本想要提高效率而引入的diff演算法使用O(n^3)的時間複雜度顯然是不太合適的，如果有1000個節點元素將需要進行十億次比較，這是一個昂貴的演算法，所以必須有一些妥協來加快速度，對比較通過一些策略進行簡化，將時間複雜度縮小到O(n)，雖然並不是最小編輯距離，但是作為編輯距離與時間效能的綜合考量是一個比較好的解決方案，是一種比較好的折中方案。

diff策略

上邊提到的O(n)時間複雜度是通過一定策略進行的，React文件中提到了兩個假設：

• 兩個不同型別的元素將產生不同的樹。
• 通過渲染器附帶key屬性，開發者可以示意哪些子元素可能是穩定的。

通俗點說就是：

• 只進行統一層級的比較，如果跨層級的移動則視為建立和刪除操作。
• 如果是不同型別的元素，則認為是建立了新的元素，而不會遞迴比較他們的孩子。
• 如果是列表元素等比較相似的內容，可以通過key來唯一確定是移動還是建立或刪除操作。

比較後會出現幾種情況，然後進行相應的操作：

• 此節點被新增或移除->新增或移除新的節點。
• 屬性被改變->舊屬性改為新屬性。
• 文字內容被改變->舊內容改為新內容。
• 節點tag或key是否改變->改變則移除後建立新元素。

分析

在分析時會簡單引用一下在React的原始碼，起輔助作用的程式碼，實際原始碼是很複雜的，引用的是一部分片段幫助理解，本文的原始碼TAG為16.10.2。
關於if (__DEV__){...}相關程式碼實際上是為更好的開發者體驗而編寫的，React中的友好的報錯，render效能測試等等程式碼都是寫在if (__DEV__)中的，在production build的時候，這些程式碼不會被打包，因此我們可以毫無顧慮的提供專為開發者服務的程式碼，React的最佳實踐之一就是在開發時使用development build，在生產環境使用production build，所以我們實際上可以先跳過這部分程式碼，專注於理解較為核心的部分。
我們分析diff演算法是從reconcileChildren開始的，之前從 setState -> enqueueSetState(UpdateQueue) -> scheduleUpdate -> performWork -> workLoop -> beginWork -> finishClassComponent -> reconcileChildren相關的部分就不過多介紹了，需要注意的是beginWork會將一個一個的Fiber來進行diff，期間是可中斷的，因為每次執行下一個Fiber的比對時，都會先判斷這一幀剩餘的時間是否充足，連結串列的每一個節點是Fiber，而不是在16之前的虛擬DOM節點，每一個Fiber都有React16的diff策略採用從連結串列頭部開始比較的演算法，是鏈式的深度優先遍歷，即已經從樹形結構變成了連結串列結構，實際相當於在15的diff演算法階段，做了優先順序的任務排程控制。此外，每個Fiber都會有一個child、sibling、return三大屬性作為連結樹前後的指標；child作為模擬樹結構的結構指標；effectTag一個很有意思的標記，用於記錄effect的型別，effect指的就是對DOM操作的方式，比如修改，刪除等操作，用於到後面進行commit(類似資料庫)；firstEffect、lastEffect等玩意是用來儲存中斷前後effect的狀態，使用者中斷後恢復之前的操作以及tag用於標記。
reconcileChildren實現的就是江湖上廣為流傳的Virtul DOM diff，其實際上只是一個入口函式，如果首次渲染，current空null，就通過mountChildFibers建立子節點的Fiber例項，如果不是首次渲染，就呼叫reconcileChildFibers去做diff，然後得出effect list。

// react-reconciler/src/ReactChildFiber.js line 1246
export function reconcileChildren(
  current: Fiber | null,
  workInProgress: Fiber,
  nextChildren: any,
  renderExpirationTime: ExpirationTime,
) {
  if (current === null) { // 首次渲染 建立子節點的`Fiber`例項
    workInProgress.child = mountChildFibers(
      workInProgress,
      null,
      nextChildren,
      renderExpirationTime,
    );
  } else { // 否則呼叫`reconcileChildFibers`去做`diff`
    workInProgress.child = reconcileChildFibers(
      workInProgress,
      current.child,
      nextChildren,
      renderExpirationTime,
    );
  }
}

對比一下mountChildFibers和reconcileChildFibers有什麼區別，可以看出他們都是通過ChildReconciler工廠函式來的，只是傳遞的引數不同而已，這個引數叫shouldTrackSideEffects，他的作用是判斷是否要增加一些effectTag，主要是用來優化初次渲染的，因為初次渲染沒有更新操作。ChildReconciler是一個超級長的工廠(包裝)函式，內部有很多helper函式，最終返回的函式叫reconcileChildFibers，這個函式實現了對子fiber節點的reconciliation。

// react-reconciler/src/ReactChildFiber.js line 1370
export const reconcileChildFibers = ChildReconciler(true);
export const mountChildFibers = ChildReconciler(false);

function ChildReconciler(shouldTrackSideEffects) { 
  // ...
  function deleteChild(){
      // ...
  }
  function useFiber(){
      // ...
  }
  function placeChild(){
      // ...
  }
  function placeSingleChild(){
      // ...
  }
  function updateTextNode(){
      // ...
  }
  function updateElement(){
      // ...
  }
  function updatePortal(){
      // ...
  }
  function updateFragment(){
      // ...
  }
  function createChild(){
      // ...
  }
  function updateSlot(){
      // ...
  }
  function updateFromMap(){
      // ...
  }
  function warnOnInvalidKey(){
      // ...
  }
  function reconcileChildrenArray(){
      // ...
  }
  function reconcileChildrenIterator(){
      // ...
  }
  function reconcileSingleTextNode(){
      // ...
  }
  function reconcileSingleElement(){
      // ...
  }
  function reconcileSinglePortal(){
      // ...
  }
  function reconcileChildFibers(){
      // ...
  }
  return reconcileChildFibers;
}

reconcileChildFibers就是diff部分的主體程式碼，相關操作都在ChildReconciler函式中，在這個函式中相關引數，returnFiber是即將diff的這層的父節點，currentFirstChild是當前層的第一個Fiber節點，newChild是即將更新的vdom節點(可能是TextNode、可能是ReactElement，可能是陣列)，不是Fiber節點。expirationTime是過期時間，這個引數是跟排程有關係的，跟diff沒有太大關係，另外需要注意的是，reconcileChildFibers 是reconcile(diff)的一層結構。

首先看TextNode的diff，他是最簡單的，對於diff TextNode會有兩種情況：

• currentFirstNode是TextNode。
• currentFirstNode不是TextNode。

分兩種情況原因就是為了複用節點，第一種情況，xxx是一個TextNode，那麼就代表這這個節點可以複用，有複用的節點，對效能優化很有幫助，既然新的child只有一個TextNode，那麼複用節點之後，就把剩下的aaa節點就可以刪掉了，那麼div的child就可以新增到workInProgress中去了。useFiber就是複用節點的方法，deleteRemainingChildren就是刪除剩餘節點的方法，這裡是從currentFirstChild.sibling開始刪除的。

if (currentFirstChild !== null && currentFirstChild.tag === HostText) {
  // We already have an existing node so let's just update it and delete
  // the rest.
  deleteRemainingChildren(returnFiber, currentFirstChild.sibling); // 刪除兄弟
  const existing = useFiber(currentFirstChild, textContent, expirationTime);
  existing.return = returnFiber;
  return existing; // 複用
}

第二種情況，xxx不是一個TextNode，那麼就代表這個節點不能複用，所以就從currentFirstChild開始刪掉剩餘的節點，其中createFiberFromText就是根據textContent來建立節點的方法，此外刪除節點不會真的從連結串列裡面把節點刪除，只是打一個delete的tag，當commit的時候才會真正的去刪除。

// The existing first child is not a text node so we need to create one
// and delete the existing ones.
// 建立新的Fiber節點，將舊的節點和舊節點的兄弟都刪除 
deleteRemainingChildren(returnFiber, currentFirstChild);
const created = createFiberFromText(
  textContent,
  returnFiber.mode,
  expirationTime,
);

接下來是React Element的diff，此時我們處理的是該節點的父節點只有此節點一個節點的情況，與上面TextNode的diff類似，他們的思路是一致的，先找有沒有可以複用的節點，如果沒有就另外建立一個。此時會用到上邊的兩個假設用以判斷節點是否可以複用，即key是否相同，節點型別是否相同，如果以上相同，則可以認為這個節點只是變化了內容，不需要建立新的節點，可以複用的。如果節點的型別不相同，就將節點從當前節點開始把剩餘的都刪除。在查詢可複用節點的時候，其並不是只專注於第一個節點是否可複用，而是繼續在該層中迴圈找到一個可以複用的節點，最頂層的while以及底部的child = child.sibling;是為了繼續從子節點中找到一個key與tag相同的可複用節點，另外刪除節點不會真的從連結串列裡面把節點刪除，只是打一個delete的tag，當commit的時候才會真正的去刪除。

// react-reconciler/src/ReactChildFiber.js line 1132
const key = element.key;
let child = currentFirstChild;
while (child !== null) {
  // TODO: If key === null and child.key === null, then this only applies to
  // the first item in the list.
  if (child.key === key) {
    if (
      child.tag === Fragment
        ? element.type === REACT_FRAGMENT_TYPE
        : child.elementType === element.type ||
          // Keep this check inline so it only runs on the false path:
          (__DEV__
            ? isCompatibleFamilyForHotReloading(child, element)
            : false)
    ) {
      deleteRemainingChildren(returnFiber, child.sibling); // 因為當前節點是隻有一個節點，而老的如果是有兄弟節點是要刪除的，是多餘的
      const existing = useFiber(
        child,
        element.type === REACT_FRAGMENT_TYPE
          ? element.props.children
          : element.props,
        expirationTime,
      );
      existing.ref = coerceRef(returnFiber, child, element);
      existing.return = returnFiber;
      // ...
      return existing;
    } else {
      deleteRemainingChildren(returnFiber, child);
      break;
    }
  } else {
    deleteChild(returnFiber, child); // 從child開始delete
  }
  child = child.sibling; // 繼續從子節點中找到一個可複用的節點
}

接下來就是沒有找到可以複用的節點因而去建立節點了，對於Fragment節點和一般的Element節點建立的方式不同，因為Fragment本來就是一個無意義的節點，他真正需要建立Fiber的是它的children，而不是它自己，所以createFiberFromFragment傳遞的不是element，而是element.props.children。

// react-reconciler/src/ReactChildFiber.js line 1178
if (element.type === REACT_FRAGMENT_TYPE) {
  const created = createFiberFromFragment(
    element.props.children,
    returnFiber.mode,
    expirationTime,
    element.key,
  );
  created.return = returnFiber;
  return created;
} else {
  const created = createFiberFromElement(
    element,
    returnFiber.mode,
    expirationTime,
  );
  created.ref = coerceRef(returnFiber, currentFirstChild, element);
  created.return = returnFiber;
  return created;
}

diff Array算是diff中最複雜的一部分了，做了很多的優化，因為Fiber樹是單連結串列結構，沒有子節點陣列這樣的資料結構，也就沒有可以供兩端同時比較的尾部遊標，所以React的這個演算法是一個簡化的雙端比較法，只從頭部開始比較，在Vue2.0中的diff演算法在patch時則是直接使用的雙端比較法實現的。
首先考慮相同位置進行對比，這個是比較容易想到的一種方式，即在做diff的時候就可以從新舊的陣列中按照索引一一對比，如果可以複用，就把這個節點從老的連結串列裡面刪除，不能複用的話再進行其他的複用策略。此時的newChildren陣列是一個VDOM陣列，所以在這裡使用updateSlot包裝成newFiber。

// react-reconciler/src/ReactChildFiber.js line 756
function reconcileChildrenArray(
    returnFiber: Fiber,
    currentFirstChild: Fiber | null,
    newChildren: Array<*>,
    expirationTime: ExpirationTime,
  ): Fiber | null {
    // 機翻註釋
    // 這個演算法不能通過兩端搜尋來優化，因為我們在光纖上沒有反向指標。我想看看我們能用這個模型走多遠。如果最終不值得權衡，我們可以稍後再新增。
    // 即使是雙端優化，我們也希望在很少有變化的情況下進行優化，並強制進行比較，而不是去尋找地圖。它想探索在前進模式下首先到達那條路徑，並且只有當我們注意到我們需要很多向前看的時候才去地圖。這不能處理反轉以及兩個結束的搜尋，但這是不尋常的。此外，要使兩端優化在Iterables上工作，我們需要複製整個集合。
    // 在第一次迭代中，我們只需在每次插入/移動時都碰到壞情況（將所有內容新增到對映中）。
    // 如果更改此程式碼，還需要更新reconcileChildrenIterator()，它使用相同的演算法。
    let oldFiber = currentFirstChild;
    let lastPlacedIndex = 0;
    let newIdx = 0;
    let nextOldFiber = null;
     // 第一個for迴圈，按照index一一對比，當新老節點不一致時退出迴圈並且記錄退出時的節點及oldFiber節點
    for (; oldFiber !== null && newIdx < newChildren.length; newIdx++) {
      if (oldFiber.index > newIdx) { // 位置不匹配
        nextOldFiber = oldFiber;  // 下一個即將對比的舊節點
        oldFiber = null; // 如果newFiber也為null(不能複用)就退出當前一一對比的for迴圈
      } else {
        nextOldFiber = oldFiber.sibling; //正常的情況下 為了下輪迴圈，拿到兄弟節點下面賦值給oldFiber
      }
      // //如果節點可以複用(key值匹配)，就更新並且返回新節點，否則返回為null，代表節點不可以複用
      const newFiber = updateSlot( // 判斷是否可以複用節點
        returnFiber,
        oldFiber,
        newChildren[newIdx],
        expirationTime,
      );
      // 節點無法複用 跳出迴圈
      if (newFiber === null) { 
        // TODO: This breaks on empty slots like null children. That's
        // unfortunate because it triggers the slow path all the time. We need
        // a better way to communicate whether this was a miss or null,
        // boolean, undefined, etc.
        if (oldFiber === null) {
          oldFiber = nextOldFiber; // 記錄不可以複用的節點並且退出對比
        }
        break; // 退出迴圈
      }
      if (shouldTrackSideEffects) {
        // 沒有複用已經存在的節點，就刪除掉已經存在的節點
        if (oldFiber && newFiber.alternate === null) {
          // We matched the slot, but we didn't reuse the existing fiber, so we
          // need to delete the existing child.
          deleteChild(returnFiber, oldFiber);
        }
      }
      // 本次遍歷會給新增的節點打 插入的標記
      lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
      if (previousNewFiber === null) {
        // TODO: Move out of the loop. This only happens for the first run.
        resultingFirstChild = newFiber;
      } else {
        // TODO: Defer siblings if we're not at the right index for this slot.
        // I.e. if we had null values before, then we want to defer this
        // for each null value. However, we also don't want to call updateSlot
        // with the previous one.
        previousNewFiber.sibling = newFiber;
      }
      previousNewFiber = newFiber;
      oldFiber = nextOldFiber;  // 重新給 oldFiber 賦值繼續遍歷
  }

在updateSlot方法中定義了判斷是否可以複用，對於文字節點,如果key不為null，那麼就代表老節點不是TextNode，而新節點又是TextNode，所以返回null，不能複用，反之則可以複用，呼叫updateTextNode方法，注意updateTextNode裡面包含了首次渲染的時候的邏輯，首次渲染的時候回插入一個TextNode，而不是複用。

// react-reconciler/src/ReactChildFiber.js line 544
function updateSlot(
    returnFiber: Fiber,
    oldFiber: Fiber | null,
    newChild: any,
    expirationTime: ExpirationTime,
  ): Fiber | null {
    // Update the fiber if the keys match, otherwise return null.

    const key = oldFiber !== null ? oldFiber.key : null;

    if (typeof newChild === 'string' || typeof newChild === 'number') {
      // 對於新的節點如果是 string 或者 number，那麼都是沒有 key 的，
      // 所有如果老的節點有 key 的話，就不能複用，直接返回 null。
      // 老的節點 key 為 null 的話，代表老的節點是文字節點，就可以複用
      if (key !== null) {
        return null;
      }
      return updateTextNode(
        returnFiber,
        oldFiber,
        '' + newChild,
        expirationTime,
      );
    }

    // ...

    return null;
}

newChild是Object的時候基本上與ReactElement的diff類似，只是沒有while了，判斷key和元素的型別是否相等來判斷是否可以複用。首先判斷是否是物件，用的是typeof newChild === object&&newChild!== null，注意要加!== null，因為typeof null也是object，然後通過$$typeof判斷是REACT_ELEMENT_TYPE還是REACT_PORTAL_TYPE，分別呼叫不同的複用邏輯，然後由於陣列也是Object，所以這個if裡面也有陣列的複用邏輯。

// react-reconciler/src/ReactChildFiber.js line 569
if (typeof newChild === 'object' && newChild !== null) {
  switch (newChild.$$typeof) {
    case REACT_ELEMENT_TYPE: { // ReactElement 
      if (newChild.key === key) {
        if (newChild.type === REACT_FRAGMENT_TYPE) {
          return updateFragment(
            returnFiber,
            oldFiber,
            newChild.props.children,
            expirationTime,
            key,
          );
        }
        return updateElement(
          returnFiber,
          oldFiber,
          newChild,
          expirationTime,
        );
      } else {
        return null;
      }
    }
    case REACT_PORTAL_TYPE: {
      // 呼叫 updatePortal
      // ...
    }
  }

  if (isArray(newChild) || getIteratorFn(newChild)) {
    if (key !== null) {
      return null;
    }

    return updateFragment(
      returnFiber,
      oldFiber,
      newChild,
      expirationTime,
      null,
    );
  }
}

讓我們回到最初的遍歷，當我們遍歷完成了之後，就會有兩種情況，即老節點已經遍歷完畢，或者新節點已經遍歷完畢，如果此時我們新節點已經遍歷完畢，也就是沒有要更新的了，這種情況一般就是從原來的陣列裡面刪除了元素，那麼直接把剩下的老節點刪除了就行了。如果老的節點在第一次迴圈的時候就被複用完了，新的節點還有，很有可能就是新增了節點的情況，那麼這個時候只需要根據把剩餘新的節點直接建立Fiber就行了。

// react-reconciler/src/ReactChildFiber.js line 839
// 新節點已經更新完成，刪除多餘的老節點
if (newIdx === newChildren.length) {
  // We've reached the end of the new children. We can delete the rest.
  deleteRemainingChildren(returnFiber, oldFiber);
  return resultingFirstChild;
}

// 新節點已經更新完成，刪除多餘的老節點
if (oldFiber === null) {
  // If we don't have any more existing children we can choose a fast path
  // since the rest will all be insertions.
  for (; newIdx < newChildren.length; newIdx++) {
    const newFiber = createChild(
      returnFiber,
      newChildren[newIdx],
      expirationTime,
    );
    if (newFiber === null) {
      continue;
    }
    lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
    if (previousNewFiber === null) {
      // TODO: Move out of the loop. This only happens for the first run.
      resultingFirstChild = newFiber;
    } else {
      previousNewFiber.sibling = newFiber;
    }
    previousNewFiber = newFiber;
  }
  return resultingFirstChild;
}

接下來考慮移動的情況如何進行節點複用，即如果老的陣列和新的陣列裡面都有這個元素，而且位置不相同這種情況下的複用，React把所有老陣列元素按key或者是index放Map裡，然後遍歷新陣列，根據新陣列的key或者index快速找到老陣列裡面是否有可複用的，元素有key就Map的鍵就存key，沒有key就存index。

// react-reconciler/src/ReactChildFiber.js line 872
// Add all children to a key map for quick lookups.
// 從oldFiber開始將已經存在的節點的key或者index新增到map結構中
const existingChildren = mapRemainingChildren(returnFiber, oldFiber);

// Keep scanning and use the map to restore deleted items as moves.
// 剩餘沒有對比的新節點，到舊節點的map中通過key或者index一一對比檢視是否可以複用。
for (; newIdx < newChildren.length; newIdx++) {
  // 主要檢視新舊節點的key或者index是否有相同的，然後再檢視是否可以複用。
  const newFiber = updateFromMap(
    existingChildren,
    returnFiber,
    newIdx,
    newChildren[newIdx],
    expirationTime,
  );
  if (newFiber !== null) {
    if (shouldTrackSideEffects) {
      if (newFiber.alternate !== null) {
        // The new fiber is a work in progress, but if there exists a
        // current, that means that we reused the fiber. We need to delete
        // it from the child list so that we don't add it to the deletion
        // list.
        existingChildren.delete(  // 在map中刪除掉已經複用的節點的key或者index
          newFiber.key === null ? newIdx : newFiber.key,
        );
      }
    }
    lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
    // 新增newFiber到更新過的newFiber結構中。
    if (previousNewFiber === null) {
      resultingFirstChild = newFiber;
    } else {
      previousNewFiber.sibling = newFiber;
    }
    previousNewFiber = newFiber;
  }
}

// react-reconciler/src/ReactChildFiber.js line 299
// 將舊節點的key或者index，舊節點儲存到map結構中，方便通過key或者index獲取
function mapRemainingChildren(
    returnFiber: Fiber,
    currentFirstChild: Fiber,
  ): Map<string | number, Fiber> {
    // Add the remaining children to a temporary map so that we can find them by
    // keys quickly. Implicit (null) keys get added to this set with their index
    // instead.
    const existingChildren: Map<string | number, Fiber> = new Map();

    let existingChild = currentFirstChild;
    while (existingChild !== null) {
      if (existingChild.key !== null) {
        existingChildren.set(existingChild.key, existingChild);
      } else {
        existingChildren.set(existingChild.index, existingChild);
      }
      existingChild = existingChild.sibling;
    }
    return existingChildren;
  }

至此新陣列遍歷完畢，也就是同一層的diff過程完畢，我們可以把整個過程分為三個階段:

• 第一遍歷新陣列，新老陣列相同index進行對比，通過updateSlot方法找到可以複用的節點，直到找到不可以複用的節點就退出迴圈。
• 第一遍歷完之後，刪除剩餘的老節點，追加剩餘的新節點的過程，如果是新節點已遍歷完成，就將剩餘的老節點批量刪除;如果是老節點遍歷完成仍有新節點剩餘，則將新節點直接插入。
• 把所有老陣列元素按key或index放Map裡，然後遍歷新陣列，插入老陣列的元素，這是移動的情況。

每日一題

https://github.com/WindrunnerMax/EveryDay

參考

https://zhuanlan.zhihu.com/p/89363990
https://zhuanlan.zhihu.com/p/137251397
https://github.com/sisterAn/blog/issues/22
https://github.com/hujiulong/blog/issues/6
https://juejin.cn/post/6844904165026562056
https://www.cnblogs.com/forcheng/p/13246874.html
https://zh-hans.reactjs.org/docs/reconciliation.html
https://zxc0328.github.io/2017/09/28/react-16-source/
https://blog.csdn.net/halations/article/details/109284050
https://blog.csdn.net/susuzhe123/article/details/107890118
https://github.com/Advanced-Frontend/Daily-Interview-Question/issues/47
https://github.com/jianjiachenghub/react-deeplearn/blob/master/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/React16%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%906-Fiber%E9%93%BE%E5%BC%8Fdiff%E7%AE%97%E6%B3%95.md