背景

深入學習 react 肯定脫離不了對 fiber 的研究，因此這篇文章記錄下 fiber 到底是什么？

React 采用 fiber 主要為了解決哪些問題？

性能問題：

• 在 React 早期版本中，當渲染大量的 DOM 節(jié)點時，由于其同步渲染機制，會導致整個渲染過程阻塞瀏覽器主線程，使得用戶界面變得不響應，甚至出現(xiàn)丟幀的問題。當狀態(tài)更新導致組件重新渲染時，React 需要重新構建整個虛擬 DOM 樹，并與之前的虛擬 DOM 樹進行比較以找出差異（diff），然后將這些差異應用到實際的 DOM 上。如果這個過程非常耗時，那么在渲染期間用戶將無法與應用交互。

用戶體驗問題：

用戶期望現(xiàn)代 Web 應用能夠快速響應他們的操作。然而，在舊版 React 中，如果某個部分正在重新渲染，那么這段時間內用戶無法得到任何反饋，這降低了用戶體驗。
為了應對這些問題，React 16 引入了 Fiber 架構，它改變了 React 的核心算法，帶來了以下改進：

• 異步渲染：Fiber 允許 React 將渲染工作分割成更小的片段，并且可以暫停、恢復這些片段，從而使得渲染工作不再是阻塞式的。這樣，即使在渲染過程中，也可以讓出執(zhí)行權給瀏覽器去處理其他任務，如事件處理和繪制。
• 優(yōu)先級調度：通過引入優(yōu)先級的概念，React 可以根據(jù)不同的情況決定哪些更新應該優(yōu)先完成。例如，用戶的直接交互通常會被賦予更高的優(yōu)先級，而一些后臺的更新則可以延遲。
• 增量渲染：Fiber 還支持增量提交，這意味著 React 可以分批次地將更改應用到真實 DOM 上，而不是一次性地進行大規(guī)模的 DOM 更新，這樣可以減少瀏覽器重排和重繪的成本。

為什么在 React 15 版本中性能會差：

瀏覽器繪制原理：

大家都知道，瀏覽器是多進程多線程的，主要進程包括主進程、渲染進程、插件進程和 GPU 進程。本次我們主要關注渲染進程，這是頁面渲染、HTML 解析、CSS 解析和 JS 執(zhí)行的地方。

在渲染進程中，有兩個核心線程：

• GUI 線程：負責瀏覽器界面的渲染，包括解析 HTML、CSS 以及布局繪制。
• JS 線程：包含我們編寫的 JS 代碼的解析引擎，最著名的是 Google 的 V8。
  需要注意的是，JS 引擎和 GUI 渲染是互斥的。JS 可能會更改 HTML 或 CSS 樣式，如果同時執(zhí)行會導致頁面渲染混亂，因此當 JS 引擎執(zhí)行時，GUI 渲染線程會被掛起，直到 JS 引擎執(zhí)行完畢。

我們通?？吹降膭赢嫼鸵曨l本質上是通過快速切換圖片來欺騙人眼，讓人感覺是連續(xù)的動畫。每秒內的圖片越多，動畫越流暢，通常 60 幀每秒（FPS）就能讓人感覺流暢。因此，Chrome 需要在 16 ms 內完成渲染任務，以避免掉幀。如果JS執(zhí)行時間過長，用戶會感覺到明顯的卡頓，很影響用戶體驗。

react 15 架構和問題

React 15 的架構主要分為 Reconciler（協(xié)調器） 和 Renderer（渲染器）。

• Reconciler（協(xié)調器），VDOM 、diff，協(xié)調器主要負責根據(jù)自變量變化計算出UI變化。
• Renderer（渲染器）， 渲染器主要負責把UI變化渲染到宿主環(huán)境中。

Reconciler 采用遞歸的方式創(chuàng)建、更新 vdom，遞歸一旦開始則不可中斷和停止，如果執(zhí)行比較復雜的深層次的 vdom 遞歸運算，則會導致 Reconciler 暫用大量時間，無法進行 Renderer 則會導致頁面卡頓。

那么 fiber 怎么解決了這個問題？

首先我們先把問題抽象一下,不要帶入 react 框架中，放入我們日常業(yè)務場景中，問題就可以轉化為 ：

一個比較大的任務，一次性處理起來耗時很長，需要我們去優(yōu)化。

既然一次性處理耗時太長，那么能不能分多次處理，可不可以只在瀏覽器空閑的時候處理，繁忙的時候先暫定處理。

任務“大”的問題

大任務的處理其實在日常開發(fā)中我們應該經(jīng)常會遇到如：“大文件上傳、加載”，“批量請求并發(fā)”等場景。我們經(jīng)常會用到切片的思想，把一個大的任務拆分成一個個小任務按照一定順序執(zhí)行，這樣我們就可以減少大任務的執(zhí)行時間，讓瀏覽器有 breathing time，讓用戶有更好的體驗。

替換到我們的場景中，vdom 就是我們的”大任務“，然后我們要切分成每一個小任務就是 fiber 節(jié)點，每一個 fiber 節(jié)點關聯(lián)起來就組成我們的 fiber 樹。

遞歸、可中斷的問題

解決了“大”的問題接下來就是遞歸的問題，之前 diff 是遞歸的不可中斷，那我們怎么才能做到可中斷呢？

原本 vdom 是一個樹結構想要遍歷只能采取遞歸的方式，我們要舍棄遞歸只能把樹結構轉化為另一種數(shù)據(jù)結構，react 采用了鏈表把每個 fiber 關聯(lián)起來，然后進行遍歷。然后再中斷的時候記錄下來當前指針，恢復時可以繼續(xù)執(zhí)行。

調度的問題

解決了“遞歸”的問題接下來就是調度的問題，我們怎么才能在瀏覽器空閑時間去調用呢?

這邊引入一個比較新鮮的 api requestIdleCallback 這個方法插入一個函數(shù)，這個函數(shù)將在瀏覽器空閑時期被調用。這使開發(fā)者能夠在主事件循環(huán)上執(zhí)行后臺和低優(yōu)先級工作，而不會影響延遲關鍵事件。這個 api 剛好就很契合我們的場景可以在瀏覽器空閑的時候去調用，我們執(zhí)行某個 fiberNode 的時候，瀏覽器主線程被占用，這個時候就可以暫停 fiberNode 的繼續(xù)執(zhí)行，等瀏覽器空閑時，繼續(xù) nextUnitOfWork。這就實現(xiàn)了可暫停可繼續(xù)。但是呢這 api 有限制：

• 兼容性問題，有的瀏覽器不支持這個 API。
• 這個方法任務執(zhí)行優(yōu)先級無法自定義，且并不符合 react 團隊的預期

總之，react 最后自己封裝了一個 Scheduler，提供更強大的事件優(yōu)先級處理邏輯，取代了 idle 的功能。具體執(zhí)行策略可以參考一下其他文章。

fiber 架構

有了這些理論思想的加持，我們再看一下 fiber 架構。

• Scheduler(調度器): 時間切片、調度任務的優(yōu)先級
• Reconciler（協(xié)調器），diff 過程，協(xié)調器主要負責根據(jù)自變量變化計算出UI變化。
• Renderer（渲染器）， 渲染器主要負責把UI變化渲染到宿主環(huán)境中。

相比我們的 react 15 多了調度器的概念，這里調度器其實就是我們上面提到的時間分片機制，控制我們的 workLoop。

fiberNode 數(shù)據(jù)結構

function Counter() {const [state, setState] = React.useState(1);return (<h1 onClick={() => setState(state + 1)}>Count: {state}</h1>);
}
//  簡單的 vdom 結構
{type: 'h1',props: {children: [{type: 'text',props: {"nodeValue": "Count",children: []}},{type: 'text',props: {"nodeValue": "1",children: []}}]}
}

可以看到這是之前的 vdom 結構, 我們需要轉化為 fiber 結構，按照我們上面切片的思想，元素結構需可以拆分成3個部分 h1、 count：、state，得到如下3個片段：

const fiber1 = {type: 'h1',props: {children: []}
}
const fiber2 = {type: 'text',props: {"nodeValue": "Count",children: []}
}
const fiber3 = {type: 'text',props: {"nodeValue": "1",children: []}
}

那怎么表示之間的關聯(lián)關系呢? 我們這邊可以通過鏈表的方式相互關聯(lián)：

• 父 -> 子: children
• 子 -> 父: return
• 兄 -> 弟: sibling

轉化為如下結構（基礎版的 fiber）：

fiber1const fiber1 = {type: 'h1',props: {children: fiber2}
}
const fiber2 = {type: 'text',props: {"nodeValue": "Count",children: null},sibling: fiber3,return : fiber1
}
const fiber3 = {type: 'text',props: {"nodeValue": "1",children: null},sibling: null,return : fiber1
}

現(xiàn)在我們已經(jīng)得到了一個 fiber 的基本結構，以下為 react 源碼中的 fiber 結構

// react/packages/react-reconciler/src/ReactInternalTypes.js
export type Fiber = {|tag: WorkTag,key: null | string,elementType: any,type: any,stateNode: any,return: Fiber | null,child: Fiber | null,sibling: Fiber | null,index: number,ref:| null| (((handle: mixed) => void) & {_stringRef: ?string, ...})| RefObject,pendingProps: any,memoizedProps: any, // 狀態(tài)updateQueue: mixed,memoizedState: any, // hooksdependencies: Dependencies | null,mode: TypeOfMode,flags: Flags,subtreeFlags: Flags,deletions: Array<Fiber> | null,nextEffect: Fiber | null,firstEffect: Fiber | null,lastEffect: Fiber | null,lanes: Lanes, // 優(yōu)先級相關childLanes: Lanes, // 優(yōu)先級相關alternate: Fiber | null, // 雙緩存actualDuration?: number,actualStartTime?: number,selfBaseDuration?: number,treeBaseDuration?: number,_debugID?: number,_debugSource?: Source | null,_debugOwner?: Fiber | null,_debugIsCurrentlyTiming?: boolean,_debugNeedsRemount?: boolean,_debugHookTypes?: Array<HookType> | null,
|};

總結

最后，那 fiber 是什么？

fiber 是 react 用于提升性能和渲染效率的一種架構，同時也是一種貫穿在整個架構中運行的數(shù)據(jù)結構。

在日常業(yè)務開發(fā)中，可能會覺得框架源碼層面的東西距離我們很遙遠，但是當我們看透本質其實會發(fā)現(xiàn)這些問題我們也遇到過，復雜問題拋開原有特殊屬性是不是就可以剝離成共性簡單問題，這或許也是我們學習源碼的意義。

問題

fiber 數(shù)據(jù)結構為什么必須是鏈表，數(shù)組不行嗎？

fiber 采用鏈表數(shù)據(jù)結構的原因是因為鏈表可以方便地在列表的中間插入和刪除元素。這在構建和更新用戶界面時非常有用，因為可能會有大量的元素需要插入或刪除。與數(shù)組相比，鏈表具有更好的插入和刪除性能，因為在數(shù)組中執(zhí)行這些操作通常需要移動大量元素，而在鏈表中只需要修改一些指針即可。

鏈表缺點：然而，鏈表的查找性能通常比數(shù)組差，因為需要遍歷整個列表才能找到所需的元素。

盡管如此，fiber 還是選擇使用鏈表作為其數(shù)據(jù)結構，因為在構建和更新用戶界面時插入和刪除元素的需求要遠遠大于查找元素的需求。