你不知道的 React Virtual DOM

什麼是 Virtual DOM ？

在前端技術蓬勃發展的上古時代，前端開發主要是一些靜態頁面，使用 ajax、jQuery 等命令式的完成一些對 DOM 的操作，而伴隨着前端工程化的不斷髮展，湧現了諸如 angular、react 等一系列 MVVM 模式的前端框架，這些框架公有的特點就是不再關心具體 DOM 的操作，而是把重點放在了基於數據狀態的操作，一旦數據更改，跟它綁定的那個地方的 DOM 也會跟着變化。這種聲明式的開發方式極大的增加了開發體驗，更好的幫助我們完成組件複用、邏輯解耦等。

藉助於上面提到的前端框架，我們不用再主動的對 DOM 進行操作，框架在背後已經替我們做了，我們只需要關心應用的數據即可。而Virtual DOM（虛擬 DOM）的概念就是在此期間由於其在React框架中的使用而變得流行起來。那麼到底什麼是Virtual DOM呢？

引用 react 官網上的介紹：

Virtual DOM 是一種編程概念。在這個概念裏， UI 以一種理想化的，或者說 “虛擬的” 表現形式被保存於內存中，並通過如 ReactDOM 等類庫使之與“真實的” DOM 同步。這一過程叫做協調。

這種方式賦予了 React 聲明式的 API：您告訴 React 希望讓 UI 是什麼狀態，React 就確保 DOM 匹配該狀態。這使您可以從屬性操作、事件處理和手動 DOM 更新這些在構建應用程序時必要的操作中解放出來。

總結來說，理解 Virtual DOM 的含義主可以從以下幾點出發：

虛擬 DOM 並不是真實的 DOM，它跟原生 DOM 本質上沒什麼關係。
本質上 Virtual DOM 對應的是一個 JavaScript 對象，它描述的是視圖和應用狀態之間的一種映射關係，是某一時刻真實 DOM 狀態的內存映射。
在視圖顯示方面，Virtual DOM 對象的節點跟真實 DOM Tree 每個位置的屬性一一對應。
我們不再需要直接的操作 DOM，只需要關注應用的狀態即可，操作 DOM 的事情有框架替我們做了。

爲什麼要用 Virtual DOM ？

======================

我們經常會說到真實的 DOM 操作代價昂貴，操作頻繁還會引起頁面卡頓影響用戶體驗，而虛擬 DOM 就是爲了解決這個瀏覽器性能問題才被創造出來。

在介紹 Virtual DOM 有什麼好處以及爲什麼要使用它之前，我們先來了解下爲什麼會說 DOM 操作是耗費性能的？

操作 DOM 是耗費性能的

首先我們要明白一點，DOM 並不屬於 JavaScript 語言的一部分，它是 JavaScript 的運行平臺（瀏覽器）提供的，比如在 nodejs 中就沒有 DOM。瀏覽器中的 DOM 對應的是 HTML 頁面中的元素節點，它本身和 JS 對象沒有什麼關聯，但是 webkit 渲染引擎和 JS 引擎之間通過 V8 Binding 在 V8 內部會把原生 DOM 對象映射爲 JS 對象，我們稱之爲 Wrapper objects（包裝對象）。因此，我們平時在寫代碼時，操作 DOM 對象就是操作的這種包裝對象，和操作 JS 對象是一樣的。下圖爲瀏覽器和 JS 引擎的關係（以 Chrome 和 V8 舉例，其他瀏覽器也大同小異）。

由於 JS 是可操縱 DOM 的，如果在修改這些元素屬性同時渲染界面（即 JS 線程和渲染線程同時運行），那麼渲染線程前後獲得的元素數據就可能不一致了。因此爲了防止渲染出現不可預期的結果，瀏覽器設置 渲染線程 與 JS 引擎線程 爲互斥的關係，當 JS 引擎執行時渲染線程會被掛起，GUI 更新則會被保存在一個隊列中等到 JS 引擎線程空閒時立即被執行。

因此我們在操作 DOM 時，任何 DOM API 調用都要先將 JS 數據結構轉爲 DOM 數據結構，再掛起 JS 引擎線程並啓動渲染引擎線程，執行過後再把可能的返回值反轉數據結構，重啓 JS 引擎繼續執行。這種兩個線程之間的上下文切換勢必會很耗性能。

另外很多 DOM API 的讀寫都涉及頁面佈局的 重繪（repaint）和迴流（reflow），這會更加的耗費性能。

綜上所述，單次 DOM API 調用性能就不夠好，頻繁調用就會迅速積累上述損耗，但我們又不可能不去操作 DOM，因此解決問題的本質是要 減少不必要的 DOM API 調用。

Virtual DOM 有什麼優勢？

很多人一談到 Virtual DOM 的優勢就會說 “原生 DOM 操作太慢了，virtual DOM 更快些”，首先我們要認識到一點：沒有任何框架可以比純手動的優化 DOM 操作更快，因爲框架的 DOM 操作層需要應對任何上層 API 可能產生的操作，它的實現必須是普適的。框架的意義在於爲你掩蓋底層的 DOM 操作，讓你用更聲明式的方式來描述你的目的，從而讓你的代碼更容易維護。

React 也從來沒有說過 “React 比原生操作 DOM 快”。並不是說 Virtual DOM 操作一定是比原生 DOM 操作快，這和具體的頁面模板大小和數據的變動量都有關係的但是相比於操作 DOM，原生的 js 對象操作起來的確是會更快、更簡單。

React.js 相對於直接操作原生 DOM 最大的優勢在於 batching 和 diff。爲了儘量減少不必要的 DOM 操作， Virtual DOM 在執行 DOM 的更新操作後，不會直接操作真實 DOM，而是根據當前應用狀態的數據，生成一個全新的 Virtual DOM，然後跟上一次生成的 Virtual DOM 去 diff，得到一個 Patch，這樣就可以找到變化了的 DOM 節點，只對變化的部分進行 DOM 更新，而不是重新渲染整個 DOM 樹，這個過程就是 diff。還有所謂的batching就是將多次比較的結果合併後一次性更新到頁面，從而有效地減少頁面渲染的次數，提高渲染效率。batching 或者 diff, 說到底，都是爲了儘量減少對 DOM 的調用。簡要的示意圖如下：

因此總結下關於 Virtual DOM 的優勢有哪些：

爲函數式的 UI 編程方式打開了大門，我們不需要再去考慮具體 DOM 的操作，框架已經替我們做了，我們就可以用更加聲明式的方式書寫代碼。
減少頁面渲染的次數，提高渲染效率。
提供了更好的跨平臺的能力，因爲 virtual DOM 是以 JavaScript 對象爲基礎而不依賴具體的平臺環境，因此可以適用於其他的平臺，如 node、weex、native 等。

附上知乎上尤雨溪對於 Virtual DOM 的優勢的回答 [1]

Virtual DOM 是如何實現的

引用 React 官網關於 Virtual DOM 的一段話：

與其將 “Virtual DOM” 視爲一種技術，不如說它是一種模式，人們提到它時經常是要表達不同的東西。在 React 的世界裏，術語 “Virtual DOM” 通常與 React 元素 [2] 關聯在一起，因爲它們都是代表了用戶界面的對象。而 React 也使用一個名爲 “fibers” 的內部對象來存放組件樹的附加信息。上述二者也被認爲是 React 中 “Virtual DOM” 實現的一部分。

下面的部分我們就來分別看看 ReactElement 和 Fiber 是什麼東西。

ReactElement

我們前面說了本質上 Virtual DOM 對應的是一個 JavaScript 對象，那麼 React 是如何通過一個 js 對象將 Virtual DOM 和真實 DOM 對應起來的呢？這裏面的關鍵就是 ReactElement。

ReactElement 即 react 元素，描述了我們在屏幕上所看到的內容，它是構成 React 應用的最小單元。比如下面的 jsx 代碼：

const element = <h1 id="hello">Hello, world</h1>

上面的代碼經過編譯後其實生成的代碼是這樣的：

React.createElement("h1", {
  id: "hello"
}, "Hello, world");

執行 React.createElement 函數，會返回類似於下面的一個 js 對象，這個對象就是我們所說的 React 元素：

const element = {
  type: 'h1',
  props: {
    id: 'hello',
    children: 'hello world'
  }
}

React 元素也可以是用戶自定義的組件：

function Button(props) {
  return <button style={{ color }}>{props.children}</button>;
}

const buttonComp = <Button color="red">點擊我</Button>

編譯後的代碼如下：

React.createElement("Button", {
  color: "red"
}, "點擊我");

因此我們就可以說 React 元素其實就是一個普通的 js 對象 (plain object)，這個對象用來描述一個 DOM 節點及其屬性或者組件的實例，當我們在 JSX 中使用 Button 組件時，就相當於調用了React.createElement()方法對組件進行了實例化。由於組件可以在其輸出中引用其他組件，當我們在構建複雜邏輯的組件時，會形成一個樹形結構的組件樹，React 便會一層層的遞歸的將其轉化爲 React 元素，當遇見 type 爲大寫的類型時，react 就會知道這是一個自定義的組件元素，然後執行組件的 render 方法或者執行該組件函數（根據是類組件或者函數組件的不同），最終返回描述 DOM 的元素進行渲染。

我們來看下 React 源碼中關於 ReactElement 和 createElement 方法的實現：

var ReactElement = function (type, key, ref, self, source, owner, props) {
  var element = {
    // This tag allows us to uniquely identify this as a React Element
    $typeof: REACT_ELEMENT_TYPE,
    // Built-in properties that belong on the element
    type: type,
    key: key,
    ref: ref,
    props: props,
    // Record the component responsible for creating this element.
    _owner: owner
  };

  // do somethings ....

  return element;
 }

 function createElement(type, config, children) {
  var propName; // Reserved names are extracted
  var props = {};
  var key = null;
  var ref = null;
  var self = null;
  var source = null;


  if (config != null) {
    if (hasValidRef(config)) {
      ref = config.ref;
      {
        warnIfStringRefCannotBeAutoConverted(config);
      }
    }
    if (hasValidKey(config)) {
      key = '' + config.key;
    }

    self = config.__self === undefined ? null : config.__self;
    source = config.__source === undefined ? null : config.__source; // Remaining properties are added to a new props object

    for (propName in config) {
      if (hasOwnProperty.call(config, propName) && !RESERVED_PROPS.hasOwnProperty(propName)) {
        props[propName] = config[propName];
      }
    }

  } // Children can be more than one argument, and those are transferred onto

  // the newly allocated props object.


  //....


  return ReactElement(type, key, ref, self, source, ReactCurrentOwner.current, props);

從上面的源碼中可以看出：

ReactElement 是通過 createElement 函數創建的。
createElement 函數接收 3 個參數，分別是 type, config, children

type 指代這個 ReactElement 的類型，它可以是 DOM 元素類型，也可以是 React 組件類型。
config 即是傳入的元素上的屬性組成的對象。
children 是一個數組，代表該元素的子元素。

爲了更加清楚的表示，我們通過在控制檯打印出整個 ReactElement 對象來看看它的真實的結構：

<div class>
    <h1>header</h1>
    <div class>content</div>
    <div>footer</div>
</div>

它最終會生成下面這樣的一個對象：

$$typeof 是一個常量 REACT_ELEMENT_TYPE，所有通過 React.createElement 生成的元素都有這個值，用來表示這是一個 React 元素。它還有一個取值，通過 createPortals 函數生成的 $$typeof 值就是 REACT_PORTAL_TYPE。
key 和 ref 從 config 對象中作爲一個特殊的配置，被單獨抽取出來，放在 ReactElement 下。
props 包含了兩部分，第一部分是去除了 key 和 ref 的 config，第二部分是 children 數組，數組的成員也是通過 React.createElement 生成的對象。
_owner 就是 Fiber，這個我們後面會講到。

通過上面這些屬性，React 就可以用 js 對象把 DOM 樹上的結構信息、屬性信息輕易的表達出來了。

React Fiber

Stack reconciler

React 15 及更早的 reconciler 架構可以分爲兩層：

Reconciler（協調器）: 負責找出變化的組件，通常將這時候的 reconciler 稱爲 stack reconciler。
Renderer（渲染器）: 負責將變化的組件渲染到頁面上。

每當有狀態更新時，Reconciler 會做如下工作：

調用函數組件、或 class 組件的 render 方法，將返回的 JSX 轉化爲 Virtual DOM。
將 Virtual DOM 和上次更新時的 Virtual DOM 對比。
通過對比找出本次更新中變化的 Virtual DOM
通知 Renderer 將變化的 Virtual DOM 渲染到頁面上，由於 React 支持跨平臺，所以不同平臺有不同的 Renderer。

它的工作流程很像是函數調用的方式，一旦 setState 之後，便開始從父節點開始遞歸的進行遍歷，找出 Virtual DOM 的不同。在將所有的 Virtual DOM 遍歷完成之後，React 才能給出當前需要更新的 DOM 信息。這個過程是個同步的過程。對於一些特別龐大的組件來說，js 執行會佔據很長的主線程時間，這樣會導致頁面響應速度變慢，出現卡頓等現象，尤其是在動畫顯示上，很可能會出現丟幀的現象。

那麼爲什麼 Stack reconsiler 會導致丟幀呢？我們來看一下一幀都做了什麼

在上面的圖中，我們可以看出一幀包括了用戶的交互行爲的處理、js 的執行、requestAnimationFrame 的調用、layout 佈局、paint 頁面重繪等工作，假如某一幀裏面要執行的任務不多，在不到 16ms（1000/60=16) 的時間內就完成了上述任務的話，頁面就會正常顯示不會出現卡頓的現象，但是如果一旦 js 執行時間過長，超過了 16ms，這一幀的刷新就沒有時間執 layout 和 paint 部分了，就可能會出現頁面卡頓的現象。

Fiber reconciler

我們仔細考慮，其實對於視圖來說，同步的改變並不是一種好的解決方案，主要有以下幾點考慮：

並不是所有的狀態更新都需要立即同步顯示，比如可視範圍之外的部分的更新。
不同類型的更新的優先級是不一樣的，比如對用戶輸入的響應一般是要比 ajax 請求的響應優先級高的。
理想情況下，對於某些高優先級的操作，應該是可以打斷低優先級的操作執行的，比如用戶輸入時，頁面的某個評論還在 reconciliation，應該優先響應用戶輸入。

爲了解決上面的 stack reconciler 中固有的問題，react 團隊重寫了核心算法 --reconciliation[3]，即 fiber reconciler（兩者之間效果對比更直觀的感受可以看下這個 demo[4]）。fiber reconciler 的架構在原來的基礎上增加了 Scheduler（調度器）的概念：

Scheduler（調度器）: 調度任務的優先級，高優任務優先進入 Reconciler。

上面我們在講一幀的過程的時候提到，假如某一幀裏面要執行的任務不多，在不到 16 ms 的時間內就完成了任務，那麼這一幀就有空閒時間，我們就可以利用這個空閒時間用來執行低優先級的任務，瀏覽器有個 api 叫 requestIdleCallback，就是指在瀏覽器的空閒時段內調用的一些函數的回調。React 實現了功能更完備的 requestIdleCallbackpolyfill，這就是 Scheduler。除了在空閒時觸發回調的功能外，Scheduler 還提供了多種調度優先級供任務設置。Scheduler 主要決定應該在何時做什麼，它在接收到更新後，首先看看有沒有其它高優先級的更新需要先執行，如果有就先執行高優先級的任務，等到空閒期再執行此次更新；如果沒有則將此次任務交給 reconciler 。

Fiber Nodes

還記得前面在講 ReactElement 時在控制檯打印出的對象裏面有個 _owner 對象嗎，它就是我們說到的 Fiber 節點。當一個 React Element 第一次被轉換爲 fiber 節點的時候， React 將會從 React Element 中提取數據並在在 createFiberFromTypeAndProps[5] 函數中創建一個新的 fiber 節點。Fiber 的主要目標是使 React 能夠利用調度。具體來說，我們需要能夠

暫停工作，稍後回來
給不同類型的工作分配優先級
重用之前已經完成的工作
當工作不再需要時取消

爲了做到這一點，我們首先需要一種將工作分解爲單元的方法。從某種意義上說，這就是 Fiber。Fiber 代表一種工作單位。React 會爲每個得到的 React Element 創建 fiber，這些 fiber 節點被連接起來組成 fiber tree。每個 fiber 對應一個 React Element，保存了該元素的類型、對應的 DOM 節點、本次更新中的該元素改變的狀態、要執行的任務（刪除、插入、更新）等信息

我們看一下 React 源碼中 FiberNode 構造函數的部分：

type 和 key 與 React 元素的用途相同，React 通過它們來判斷 Fiber 是否可以重複使用。
stateNode 是 Fiber 對應的真實 DOM 節點。
多個 fiber 節點中是怎麼連接形成 fiber tree 的呢？主要靠以下三個屬性：
return：指向父級 Fiber 節點；
child：指向子級 fiber 節點；
sibling：指向右邊第一個兄弟 fiber 節點；

在 React Fiber 中，一次更新過程會分成多個分片完成，所以完全有可能一個更新任務還沒有完成，就被另一個更高優先級的更新過程打斷，這時候，優先級高的更新任務會優先處理完，而低優先級更新任務所做的工作則會完全作廢，然後等待機會重頭再來。因爲一個更新過程可能被打斷，所以 React Fiber 一個更新過程被分爲兩個階段 (Phase)：第一個階段 Reconciliation Phase**** 和第二階段 **Commit Phase**。在第一階段 Reconciliation Phase，React Fiber 會找出需要更新哪些 DOM，這個階段是可以被打斷的；但是到了第二階段 Commit Phase，那就一鼓作氣把 DOM 更新完，絕不會被打斷。

雙緩衝 Fiber tree

在 React 中最多會同時存在兩棵fiber tree。當前屏幕上顯示內容對應的fiber tree稱爲current fiber tree，正在內存中構建的fiber tree稱爲workInProgress fiber tree。current fiber tree 中的 Fiber 節點被稱爲 current fiber，workInProgress fiber tree 中的 Fiber 節點被稱爲 workInProgress fiber，他們通過 alternate 屬性連接。

currentFiber.alternate === workInProgressFiber;

workInProgressFiber.alternate === currentFiber;

React 應用的根節點通過current指針在不同fiber tree的rootFiber間切換來實現fiber tree的切換。雙緩衝具體指的是當workInProgress fiber tree構建完成交給Renderer渲染在頁面上後，應用根節點的current指針指向workInProgress fiber tree，此時workInProgress fiber tree就變爲current fiber tree。每次狀態更新都會產生新的workInProgress fiber tree，通過current與workInProgress的替換，完成 DOM 更新。這樣做的好處是：

能夠複用內部對象（fiber）
節省內存分配、GC 的時間開銷

總結

前面我們瞭解了 ReactElement 和 React Fiber，現在總結一下整個 Virtual DOM 的工作流程。

初始化渲染，調用函數組件、或 class 組件的 render 方法，將 JSX 代碼編譯成 ReactELement 對象，它描述當前組件內容的數據結構。
根據生產的 ReactELement 對象構建 Fiber tree，它包含了組件 schedule、reconciler、render 所需的相關信息。
一旦有狀態變化，觸發更新，Scheduler 在接收到更新後，根據任務的優先級高低來進行調度，決定要執行的任務是什麼。
接下來的工作交給 Reconciler 處理，Reconciler 通過對比找出變化了的 Virtual DOM ，爲其打上代表增 / 刪 / 更新的標記，當所有組件都完成 Reconciler 的工作，纔會統一交給 Renderer。
Renderer 根據 Reconciler 爲 Virtual DOM 打的標記，同步執行對應的 DOM 更新操作。

Diff 算法

在調用 React 的 render() 方法，會創建一棵由 React 元素組成的樹。在下一次 state 或 props 更新時，相同的 render() 方法會返回一棵不同的樹。React 需要基於這兩棵樹之間的差別來進行比較，這個比較的過程就是俗稱的 diff 算法，換成前面我們講的 React Fiber 的概念來說，就是將當前組件與該組件在上次更新時對應的 Fiber node 比較，將比較的結果生成新的 Fiber 節點。爲了方便理解，我們列舉下這個更新的 DOM 節點在某一時刻會有這麼幾個概念與其相關：

current Fiber：如果該 DOM 節點已在頁面中，current Fiber 代表該 DOM 節點對應的 Fiber node。
workInProgress Fiber: workInProgress Fiber 代表了正在內存中構建的 Fiber 節點，如果該 DOM 節點即將在本次更新中渲染到頁面中，則 workInProgress Fiber 代表該 DOM 節點對應的 Fiber 節點，就是最後更新的結果。
ReactElement 對象：即前面講到的 Class 組件 render 方法或者調用函數組件的結果經過 React.createElement 生成的對象。

Diff 算法的本質就是對比 1 和 3，生成 2。

Diff 策略

React 文檔中提到，即使在最前沿的算法中 [6]，將前後兩棵樹完全比對的算法的複雜程度爲 O(n 3)，其中 n 是樹中元素的數量。如果在 React 中使用了該算法，那麼展示 1000 個元素所需要執行的計算量將在十億的量級範圍。這個開銷實在是太過高昂，顯然無法滿足性能要求，於是 React 在以下兩個假設的基礎之上提出了一套 O(n) 的啓發式算法：

只對同級元素進行 Diff，如果某一個節點在一次更新中跨域了層級，React 不會複用該節點，而是重新創建生成新的節點。
兩個不同類型的元素會產生出不同的樹，如果元素由 div 變爲 p，React 會銷燬 div 及其子孫節節點，並新建 p 及其子孫節點。
開發者可以通過 key prop 來暗示哪些子元素在不同的渲染下能保持穩定；

如上圖所示，React 只會對相同顏色框內的 DOM 節點進行比較，即同一個父節點下的所有子節點。當發現節點已經不存在，則該節點及其子節點會被完全刪除掉，不會用於進一步的比較。這樣只需要對樹進行一次遍歷，便能完成整個 DOM 樹的比較。當有下面的情況時（A 節點直接被整個移動到 D 節點下）

因爲 React 只會對同級節點進行比較，這時候 React 發現的是 A 節點不見了，就會直接銷燬 A 節點，在 D 節點那裏發現多了一個新的子節點 A，則會創建一個新的 A 節點作爲子節點。

上面的例子是對於在不同層級的節點的比較，對於同一層級的節點，React 引入了 key 屬性來來給每一個節點添加唯一標識，這樣 React 就能匹配到原有的節點，提高轉換效率，如下面的例子：

// 更新前
<ul>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

// 更新後
<ul>
  <li key="2014">Connecticut</li>
  <li key="2015">Duke</li>
  <li key="2016">Villanova</li>
</ul>

如果沒有 key 值，React 會重新創建每一個子元素，因爲在比較 ul 的第一個子元素時發現兩者不同，即開始重建，但當子元素擁有 key 時，React 使用 key 來匹配原有樹上的子元素以及最新樹上的子元素，現在 React 知道只有帶着 '2014' key 的元素是新元素，帶着 '2015' 以及 '2016' key 的元素僅僅移動了。

所以我們在寫代碼時遇到列表渲染的時候，一定要記得給列表的每一項加上 key 屬性，這個 key 不需要全局唯一，但在列表中需要保持唯一。

Diff 算法的實現

我們從 Diff 的入口函數 reconcileChildFibers 出發，該函數會根據 newChild（即 ReactElement 對象）類型調用不同的處理函數。其中幾個參數的含義如下：

newChild：即當前更新新生成的 ReactElement 對象。
returnFiber：代表當前 Diff 的節點的父級 Fiber 節點，也就是上次更新時的 Fiber 節點。
currentFirstChild：即與 newChild 進行 diff 的節點，也是 returnFiber 的第一個子節點。

我們可以從同級的節點數量將 Diff 分爲兩類：

當 newChild 類型爲 object、number、string，代表同級只有一個節點
當 newChild 類型爲 Array，同級有多個節點

單節點 Diff

對於單個節點，我們以類型 object 爲例，會進入 reconcileSingleElement 函數里，這個函數主要做了以下事情：

reconcileSingleElement 方法的部分代碼如下：

function reconcileSingleElement(
  returnFiber: Fiber,
  currentFirstChild: Fiber | null,
  element: ReactElement
): Fiber {

  const key = element.key;

  let child = currentFirstChild;

  // 首先判斷是否存在對應DOM節點

  while (child !== null) {
    // 上一次更新存在DOM節點，接下來判斷是否可複用

    // 首先比較key是否相同
    if (child.key === key) {

      // key相同，接下來比較type是否相同
      switch (child.tag) {
        // ...省略case

        default: {
          if (child.elementType === element.type) {
            // type相同則表示可以複用
            // 返回複用的fiber
            return existing;
          }
          // type不同則跳出循環
          break;
        }
      }

      // 代碼執行到這裏代表：key相同但是type不同
      // 將該fiber及其兄弟fiber標記爲刪除
      deleteRemainingChildren(returnFiber, child);
      break;
    } else {
      // key不同，將該fiber標記爲刪除
      deleteChild(returnFiber, child);
    }
    child = child.sibling;
  }


  // 創建新Fiber，並返回 ...省略

}

多節點 Diff

當 ReactElement 的 children 屬性不是單一節點的話，如下面結構：

 <ul>
    <li key="0">0</li>
    <li key="1">1</li>
    <li key="2">2</li>
    <li key="3">3</li>
 </ul>

此時它返回的對象的 children 是包含 4 個對象的數組：

{

  $typeof: Symbol(react.element),
  key: null,
  props: {
    children: [
      {$typeof: Symbol(react.element), type: "li", key: "0", ref: null, props: {…}, …}
      {$typeof: Symbol(react.element), type: "li", key: "1", ref: null, props: {…}, …}
      {$typeof: Symbol(react.element), type: "li", key: "2", ref: null, props: {…}, …}
      {$typeof: Symbol(react.element), type: "li", key: "3", ref: null, props: {…}, …}
    ]
  },
  ref: null,
  type: "ul"
}

這種情況下，reconcileChildFibers的newChild參數類型爲Array，對應的處理函數是reconcileChildrenArray裏的newChildren，在比較時，和newChildren裏的每一個child比較的是current fiber，即newChildren[0]與fiber比較，newChildren[1]與fiber.sibling比較。

多節點 diff 的情況比較多比較複雜，大致可以分爲以下幾個方面：

節點更新

節點屬性變化
節點類型變化

節點增加或減少
節點位置發生變化

React 團隊發現，在日常開發中，相較於新增和刪除，更新組件發生的頻率更高。所以 Diff 會優先判斷當前節點是否屬於更新。基於以上原因，Diff 算法的整體邏輯會經歷兩輪：

第一輪遍歷：處理更新的節點。
第二輪遍歷：處理剩下的不屬於更新的節點。

第一輪遍歷的步驟如下：

遍歷 newChildren，將 newChildren[i] 與 oldFiber 比較，判斷 DOM 節點是否可複用。
如果可複用，i++，繼續比較 newChildren[i] 與 oldFiber.sibling，可以複用則繼續遍歷。
如果不可複用，立即跳出整個遍歷，第一輪遍歷結束。
如果 newChildren 遍歷完（即 i === newChildren.length - 1）或者 oldFiber 遍歷完（即 oldFiber.sibling === null），跳出遍歷，第一輪遍歷結束。

第一輪遍歷結束後，有以下幾種結果：

newChildren 與 oldFiber 同時遍歷完：這說明新舊節點數量一樣，只是組件發生了更新。此時 Diff 結束。
newChildren 沒遍歷完，oldFiber 遍歷完：這說明舊的節點遍歷完了，但是還有新加入的節點，我們只需要遍歷剩下的 newChildren 爲生成的 workInProgress fiber 依次標記上 Placement。
newChildren 遍歷完，oldFiber 沒遍歷完：這說明本次更新比之前的節點數量變少了，有節點被刪除了，所以要遍歷剩下的 oldFiber，依次標記 Deletion。
newChildren 與 oldFiber 都沒遍歷完：這意味着有節點在這次更新中改變了位置，這時候需要通過 key 來標記節點是否移動。

等上面所有的節點都遍歷完成後，都已經打上了增 / 刪 / 更新的標記，此時就生成了 workInProgress Fiber，剩下的工作就是交個 renderer 處理了。

參考資料

[1]

尤雨溪對於 Virtual DOM 的優勢的回答: https://www.zhihu.com/question/31809713/answer/53544875

[2]

React 元素: https://zh-hans.reactjs.org/docs/rendering-elements.html

[3]

reconciliation: https://reactjs.org/docs/reconciliation.html

[4]

demo: https://claudiopro.github.io/react-fiber-vs-stack-demo/

[5]

createFiberFromTypeAndProps: https://github.com/facebook/react/blob/769b1f270e1251d9dbdce0fcbd9e92e502d059b8/packages/react-reconciler/src/ReactFiber.js#L414

[6]

最前沿的算法中: http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ixouNzFB-E54_4GTngCBuQ