從源碼中來，到業務中去，React性能優化終極指南
前言
React性能優化是在業務迭代過程中不得不考慮的問題，大部分情況是由于項目啟動之初，沒有充分考慮到項目的復雜度，定位該產品的用戶體量及技術場景并不復雜，那么我們在業務前期可能并不需要考慮性能優化。但是隨著業務場景的復雜化，性能優化就變得格外重要。
我們從React源碼入手，結合有道精品課大前端的具體業務，運用優化技巧對系統進行外科手術式的優化。同時介紹一下React Profiler這款性能優化的利器是如何幫我們定位性能瓶頸的。
本文中的項目代碼全部是在有道大前端組開發項目中的工作記錄，如有不足歡迎在留言區討論交流，筆芯❤
頁面加載流程
-
假設用戶首次打開頁面（無緩存），這個時候頁面是完全空白的；
-
html 和引用的 css 加載完畢，瀏覽器進行 首次渲染 ；
-
react、react-dom、業務代碼加載完畢，應用第一次渲染，或者說 首次內容渲染 ；
-
應用的代碼開始執行，拉取數據、進行動態import、響應事件等等，完畢后頁面進入 可交互 狀態；
-
接下來 lazyload 的圖片等多媒體內容開始逐漸加載完畢；
-
直到頁面的其它資源（如錯誤上報組件、打點上報組件等）加載完畢，整個頁面加載完成。
我們主要來針對React進行剖析：
React 針對渲染性能優化的三個方向，也適用于其他軟件開發領域，這三個方向分別是:
-
減少計算的量：React 中就是減少渲染的節點或通過索引減少渲染復雜度；
-
利用緩存：React 中就是避免重新渲染（利用 memo 方式來避免組件重新渲染）；
-
精確重新計算的范圍：React 中就是綁定組件和狀態關系, 精確判斷更新的'時機'和'范圍'. 只重新渲染變更的組件（減少渲染范圍）。
如何做到這三點呢？我們從React本身的特性入手分析。
React 工作流
React 是聲明式 UI 庫，負責將 State 轉換為頁面結構（虛擬 DOM 結構）后，再轉換成真實 DOM 結構，交給瀏覽器渲染。State 發生改變時，React 會先進行Reconciliation，結束后立刻進入Commit階段，Commit結束后，新 State 對應的頁面才被展示出來。
React 的 Reconciliation 需要做兩件事：
-
計算出目標 State 對應的虛擬 DOM 結構。
-
尋找「將虛擬 DOM 結構修改為目標虛擬 DOM 結構」的最優方案。
React 按照深度優先遍歷虛擬 DOM 樹的方式，在一個虛擬 DOM 上完成Render和Diff的計算后，再計算下一個虛擬 DOM。Diff 算法會記錄虛擬 DOM 的更新方式（如：Update、Mount、Unmount），為Commit做準備。
React 的 Commit 也需要做兩件事：
-
將Reconciliation結果應用到 DOM 中。
-
調用暴露的hooks如：componentDidUpdate、useLayoutEffect 等。
下面我們將針對三個優化方向進行精準分析。
01 減少計算的量
關于以上 Reconciliation 與 Commit 兩個階段的優化辦法，我在實現的過程中遵循 減少計算量 的方法進行優化（ 列表項使用 key 屬性 )該過程是優化的重點，React 內部的 Fiber 結構和并發模式也是在減少該過程的耗時阻塞。對于 Commit 在執行hooks時，開發者應保證hooks中的代碼盡量輕量，避免耗時阻塞，同時應避免在 CDM、CDU周期 中更新組件。
列表項使用 key 屬性
特定框架中，提示也做的十分友好。假如你沒有在列表中添加key屬性，控制臺會為你展示一片大紅
系統會時刻提醒你記得加Key哦~~
1.1 優化Render 過程
Render 過程：即 Reconciliation 中計算出目標 State 對應的虛擬 DOM 結構這一階段 。
觸發 React 組件的 Render 過程目前有三種方式：
-
forceUpdate、
-
State 更新、
-
父組件 Render 觸發子組件 Render 過程。
●優化技巧
PureComponent、React.memo
在 React 工作流中，如果只有父組件發生狀態更新，即使父組件傳給子組件的所有 Props 都沒有修改，也會引起子組件的 Render 過程。
從 React 的聲明式設計理念來看，如果子組件的 Props 和 State 都沒有改變，那么其生成的 DOM 結構和副作用也不應該發生改變。當子組件符合聲明式設計理念時，就可以忽略子組件本次的 Render 過程。
PureComponent 和 React.memo 就是應對這種場景的，PureComponent 是對類組件的 Props 和 State 進行淺比較，React.memo 是對函數組件的 Props 進行淺比較。
-
useMemo、useCallback 實現穩定的 Props 值
如果傳給子組件的派生狀態或函數，每次都是新的引用，那么 PureComponent 和 React.memo 優化就會失效。所以需要使用 useMemo 和 useCallback 來生成穩定值，并結合 PureComponent 或 React.memo 避免子組件重新 Render。
-
useMemo 減少組件 Render 過程耗時
useMemo 是一種緩存機制提速，當它的依賴未發生改變時，就不會觸發重新計算。一般用在「計算派生狀態的代碼」非常耗時的場景中，如：遍歷大列表做統計信息。
大列表渲染
-
顯然 useMemo 的作用是緩存昂貴的計算(避免在每次渲染時都進行高開銷的計算)，在業務中使用它去控制變量來更新表格
shouldComponentUpdate
在類組件中，例如要往數組中添加一項數據時，當時的代碼很可能是 state.push(item)，而不是 const newState = [...state, item]。
在此背景下，當時的開發者經常使用 shouldComponentUpdate 來深比較 Props，只在 Props 有修改才執行組件的 Render 過程。如今由于數據不可變性和函數組件的流行，這樣的優化場景已經不會再出現了。
為了貼合shouldComponentUpdate的思想：給子組件傳props的時候一定只傳其需要的而并非一股腦全部傳入：
傳入到子組件的參數一定保證其在自組件中被使用到。
1.2 批量更新，減少 Render 次數
在 React 管理的事件回調和生命周期中，setState 是異步的，而其他時候 setState 都是同步的。這個問題根本原因就是 React 在自己管理的事件回調和生命周期中，對于 setState 是批量更新的，而在其他時候是立即更新的。
批量更新 setState 時，多次執行 setState 只會觸發一次 Render 過程。相反在立即更新 setState 時，每次 setState 都會觸發一次 Render 過程，就存在性能影響。
假設有如下組件代碼，該組件在 getData() 的 API 請求結果返回后，分別更新了兩個 State 。
該組件會在 setList(data.list) 后觸發組件的 Render 過程，然后在 setInfo(data.info) 后再次觸發 Render 過程，造成性能損失。那我們該如何解決呢：
-
將多個 State 合并為單個 State。例如 useState({ list: null, info: null }) 替代 list 和 info 兩個 State。
-
使用 React 官方提供的 unstable_batchedUpdates 方法，將多次 setState 封裝到 unstable_batchedUpdates 回調中。
修改后代碼如下：
02 精細化渲染階段
2.1 按優先級更新，及時響應用戶
優先級更新是批量更新的逆向操作，其思想是：優先響應用戶行為，再完成耗時操作。常見的場景是：頁面彈出一個 Modal，當用戶點擊 Modal 中的確定按鈕后，代碼將執行兩個操作：
-
關閉 Modal。
-
頁面處理 Modal 傳回的數據并展示給用戶。
當操作2需要執行500ms時，用戶會明顯感覺到從點擊按鈕到 Modal 被關閉之間的延遲。
以下為一般的實現方式，將 slowHandle 函數作為用戶點擊按鈕的回調函數。
非延遲執行
slowHandle() 執行過程耗時長，用戶點擊按鈕后會明顯感覺到頁面卡頓。
如果讓頁面優先隱藏輸入框，用戶便能立刻感知到頁面更新，不會有卡頓感。
實現優先級更新的要點是將耗時任務移動到下一個宏任務中執行，優先響應用戶行為。
例如在該例中，將 setNumbers 移動到 setTimeout 的回調中，用戶點擊按鈕后便能立即看到輸入框被隱藏，不會感知到頁面卡頓。mhd項目中優化后的代碼如下：
延遲執行
2.2 發布者訂閱者跳過中間組件 Render 過程
React 推薦將公共數據放在所有「需要該狀態的組件」的公共祖先上，但將狀態放在公共祖先上后，該狀態就需要層層向下傳遞，直到傳遞給使用該狀態的組件為止。
傳統redux數據流
每次狀態的更新都會涉及中間組件的 Render 過程，但中間組件并不關心該狀態，它的 Render 過程只負責將該狀態再傳給子組件。在這種場景下可以將狀態用發布者訂閱者模式維護，只有關心該狀態的組件才去訂閱該狀態，不再需要中間組件傳遞該狀態。
當狀態更新時，發布者發布數據更新消息，只有訂閱者組件才會觸發 Render 過程，中間組件不再執行 Render 過程。
只要是發布者訂閱者模式的庫，都可以使用useContext進行該優化。比如：redux、use-global-state、React.createContext 等。
業務代碼中的使用如下：
從圖中可看出，優化后只有使用了公共狀態的組件renderTable才會發生更新，由此可見這樣做可以大大減少父組件和 其他renderSon... 組件的 Render 次數(減少葉子節點的重渲染)。
2.3 useMemo 返回虛擬 DOM 可跳過該組件 Render 過程
利用 useMemo 可以緩存計算結果的特點，如果 useMemo 返回的是組件的虛擬 DOM，則將在 useMemo 依賴不變時，跳過組件的 Render 階段。
該方式與 React.memo 類似，但與 React.memo 相比有以下優勢：
-
更方便。React.memo 需要對組件進行一次包裝，生成新的組件。而 useMemo 只需在存在性能瓶頸的地方使用，不用修改組件。
-
更靈活。useMemo 不用考慮組件的所有 Props，而只需考慮當前場景中用到的值，也可使用 useDeepCompareMemo 對用到的值進行深比較。
該例子中，父組件狀態更新后，不使用 useMemo 的子組件會執行 Render 過程，而使用 useMemo 的子組件會按需執行更新。業務代碼中的使用方法：
03 精確判斷更新的'時機'和'范圍'
3.1 debounce、throttle 優化頻繁觸發的回調
在搜索組件中，當 input 中內容修改時就觸發搜索回調。當組件能很快處理搜索結果時，用戶不會感覺到輸入延遲。
但實際場景中，中后臺應用的列表頁非常復雜，組件對搜索結果的 Render 會造成頁面卡頓，明顯影響到用戶的輸入體驗。
在搜索場景中一般使用 useDebounce+ useEffect 的方式獲取數據。
在搜索場景中，只需響應用戶最后一次輸入，無需響應用戶的中間輸入值，debounce 更適合。而 throttle 更適合需要實時響應用戶的場景中更適合，如通過拖拽調整尺寸或通過拖拽進行放大縮小（如：window 的 resize 事件）。
3.2 懶加載
在 SPA 中，懶加載優化一般用于從一個路由跳轉到另一個路由。
還可用于用戶操作后才展示的復雜組件，比如點擊按鈕后展示的彈窗模塊（大數據量彈窗）。
在這些場景下，結合 Code Split 收益較高。懶加載的實現是通過 Webpack 的動態導入和 React.lazy 方法。
實現懶加載優化時，不僅要考慮加載態，還需要對加載失敗進行容錯處理。
3.3 懶渲染
懶渲染指當組件進入或即將進入可視區域時才渲染組件。常見的組件 Modal/Drawer 等，當 visible 屬性為 true 時才渲染組件內容，也可以認為是懶渲染的一種實現。懶渲染的使用場景有：
-
頁面中出現多次的組件，且組件渲染費時、或者組件中含有接口請求。如果渲染多個帶有請求的組件，由于瀏覽器限制了同域名下并發請求的數量，就可能會阻塞可見區域內的其他組件中的請求，導致可見區域的內容被延遲展示。
-
需用戶操作后才展示的組件。這點和懶加載一樣，但懶渲染不用動態加載模塊，不用考慮加載態和加載失敗的兜底處理，實現上更簡單。
懶渲染的實現中判斷組件是否出現在可視區域內借助react-visibility-observer依賴：
3.4 虛擬列表
虛擬列表是懶渲染的一種特殊場景。虛擬列表的組件有 react-window和 react-virtualized，它們都是同一個作者開發的。
react-window 是 react-virtualized 的輕量版本，其 API 和文檔更加友好。推薦使用 react-window，只需要計算每項的高度即可：
如果每項的高度是變化的，可給 itemSize 參數傳一個函數。
所以在開發過程中，遇到接口返回的是所有數據時，需提前預防這類會有展示的性能瓶頸的需求時，推薦使用虛擬列表優化。 使用示例可以點擊【閱讀原文】查看。
3.5 動畫庫直接修改 DOM 屬性，跳過組件 Render 階段
這個優化在業務中應該用不上，但還是非常值得學習的，將來可以應用到組件庫中。
參考 react-spring 的動畫實現，當一個動畫啟動后，每次動畫屬性改變不會引起組件重新 Render ，而是直接修改了 dom 上相關屬性值：
3.6 避免在 didMount、didUpdate 中更新組件 State
這個技巧不僅僅適用于 didMount、didUpdate，還包括 willUnmount、useLayoutEffect 和特殊場景下的 useEffect（當父組件的 cDU/cDM 觸發時，子組件的 useEffect 會同步調用），本文為敘述方便將他們統稱為「提交階段鉤子」。
React 工作流commit階段的第二步就是執行提交階段鉤子，它們的執行會阻塞瀏覽器更新頁面。
如果在提交階段鉤子函數中更新組件 State，會再次觸發組件的更新流程，造成兩倍耗時。一般在提交階段的鉤子中更新組件狀態的場景有：
-
計算并更新組件的派生狀態（Derived State）。在該場景中，類組件應使用 getDerivedStateFromProps 鉤子方法代替，函數組件應使用函數調用時執行 setState 的方式代替。使用上面兩種方式后，React 會將新狀態和派生狀態在一次更新內完成。
-
根據 DOM 信息，修改組件狀態。在該場景中，除非想辦法不依賴 DOM 信息，否則兩次更新過程是少不了的，就只能用其他優化技巧了。
use-swr 的源碼就使用了該優化技巧。當某個接口存在緩存數據時，use-swr 會先使用該接口的緩存數據，并在 requestIdleCallback 時再重新發起請求，獲取最新數據。模擬一個swr：
-
它的第二個參數 deps，是為了在請求帶有參數時，如果參數改變了就重新發起請求。
-
暴露給調用方的 fetch 函數，可以應對主動刷新的場景，比如頁面上的刷新按鈕。
如果 use-swr 不做該優化的話，就會在 useLayoutEffect 中觸發重新驗證并設置 isValidating 狀態為 true·，引起組件的更新流程，造成性能損失。
04 工具介紹——React Profiler
4.1 React Profiler 定位 Render 過程瓶頸
React Profiler 是 React 官方提供的性能審查工具，本文只介紹筆者的使用心得，詳細的使用手冊請移步官網文檔。
Note：react-dom 16.5+ 在 DEV 模式下才支持 Profiling，同時生產環境下也可以通過一個 profiling bundle react-dom/profiling 來支持。請在 fb.me/react-profi… 上查看如何使用這個 bundle。
“Profiler” 的面板在剛開始的時候是空的。你可以點擊 record 按鈕來啟動 profile：
4.2 Profiler 只記錄了 Render 過程耗時
不要通過 Profiler 定位非 Render 過程的性能瓶頸問題
通過 React Profiler，開發者可以查看組件 Render 過程耗時，但無法知曉提交階段的耗時。
盡管 Profiler 面板中有 Committed at 字段，但這個字段是相對于錄制開始時間，根本沒有意義。
通過在 React v16 版本上進行實驗，同時開啟 Chrome 的 Performance 和 React Profiler 統計。
如下圖，在 Performance 面板中，Reconciliation和Commit階段耗時分別為 642ms 和 300ms，而 Profiler 面板中只顯示了 642ms：
4.3 開啟「記錄組件更新原因」
點擊面板上的齒輪，然后勾選「Record why each component rendered while profiling.」，如下圖 ：
然后點擊面板中的虛擬 DOM 節點，右側便會展示該組件重新 Render 的原因 。
4.4 定位產生本次 Render 過程原因
由于 React 的批量更新（Batch Update）機制，產生一次 Render 過程可能涉及到很多個組件的狀態更新。那么如何定位是哪些組件狀態更新導致的呢？
在 Profiler 面板左側的虛擬 DOM 樹結構中，從上到下審查每個發生了渲染的（不會灰色的）組件。
如果組件是由于 State 或 Hook 改變觸發了 Render 過程，那它就是我們要找的組件，如下圖：
4.5 站在巨人的肩膀上
Optimizing Performance
https://react.docschina.org/docs/optimizing-performance.html
React 官方文檔，最好的教程, 利用好 React 的性能分析工具。
Twitter Lite and High Performance React Progressive Web Apps at Scale
https://medium.com/@paularmstrong/twitter-lite-and-high-performance-react-progressive-web-apps-at-scale-d28a00e780a3
看看 Twitter 是如何優化的。
