如何方便的檢測React項目的性能？
大家好，我卡頌。
對于長期迭代的React項目，性能是不能忽視的問題。通常我們通過：
- React-Dev-Tools的Profiler面板
- 一些第三方工具，比如why-did-you-render[1]
檢測運行時性能瓶頸。
實際上，React本身就內(nèi)置了性能檢測組件 —— Profiler，可以很方便的檢測React項目的性能。
使用方式
Profiler是個內(nèi)置組件，用他包裹需要檢測性能的組件即可：
<Profiler id="App" onRender={onRender}>
<App />
</Profiler>嵌套使用也是可以的：
<App>
<Profiler id="Sidebar" onRender={onRender}>
<Sidebar />
</Profiler>
<Profiler id="Content" onRender={onRender}>
<Content />
</Profiler>
</App>Profiler會檢測被他包裹的組件樹的性能，檢測結(jié)果會作為onRender回調(diào)的參數(shù)：
function onRender(
id,
phase,
actualDuration, baseDuration,
startTime, commitTime
) {
// ...回調(diào)
}那么，這些參數(shù)都是什么意思呢？其實我們完全沒必要記這些。
我們只需要知道，一些典型的性能優(yōu)化場景該使用哪些參數(shù)就行。
場景1：組件是不是嵌套更新？
對于一般的組件更新，會經(jīng)歷4個步驟：
- 組件觸發(fā)更新
- 計算更新的影響
- 執(zhí)行DOM操作
- 視圖更新
但如果在上一次更新流程的4個步驟還未走完的情況下，又觸發(fā)新的更新：
可以發(fā)現(xiàn)，在這種情況下，「視圖更新」的時機遠(yuǎn)滯后于一般更新流程，這會造成頁面交互卡頓。
這就是「組件嵌套更新」，通常我們在useLayoutEffect中觸發(fā)新的更新會遇到這種情況。
Profiler onRender回調(diào)的phase參數(shù)，用來表示組件所處更新階段：
- mount，代表組件是首屏渲染。
- update，代表組件更新。
- nested-update，代表組件嵌套更新。
通過該參數(shù)可以判斷組件是否處于嵌套更新。
當(dāng)遇到嵌套更新造成的性能問題，可以考慮用useEffect替代useLayoutEffect。
場景2：性能優(yōu)化到底起沒起作用？
當(dāng)提到「性能優(yōu)化」，很多同學(xué)第一反應(yīng)就是：
- useCallback
- useMemo
- React.memo
但當(dāng)我們使用這些性能優(yōu)化API后，我們怎么知道性能是否變得更好？
為了檢測優(yōu)化效果，通常會在關(guān)鍵組件打印個log，如果狀態(tài)更新后log沒打印，代表組件沒有render，命中緩存成功，比如這樣：
function App() {
console.log('App render')
// ...省略邏輯
}但這樣并不能反映性能優(yōu)化的整體效果。這時候可以考慮Profiler中的actualDuration與baseDuration參數(shù)：
- baseDuration衡量組件子樹在不命中任何緩存時，完整render一次所花時間。
- actualDuration衡量組件子樹實際完整render一次所花時間。
所以，用baseDuration減去actualDuration剩余的時間，就是性能優(yōu)化節(jié)約的時間。
比如，對下面的<App/>組件性能優(yōu)化后，只需要在onRender中比較baseDuration與actualDuration之間的差就能度量<App />的性能優(yōu)化效果：
<Profiler id="App" onRender={onRender}>
<App />
</Profiler>這個值越高，代表性能優(yōu)化效果越好。當(dāng)接近0時，代表性能優(yōu)化沒有起到作用。
需要注意的是，baseDuration是通過子樹中每個組件最近render所需時間匯總求和得到的近似值，有時并不準(zhǔn)確
如果你的同事固執(zhí)的認(rèn)為所有函數(shù)props都必須用useCallback包裹，所有變量props都必須用useMemo包裹，請用以上數(shù)據(jù)狠狠的和他講道理。
場景3：項目的性能瓶頸在哪？
當(dāng)我們要做性能優(yōu)化時，首先應(yīng)該明確 —— 項目的性能瓶頸在哪？此時，可以用Profiler劃分幾個「待比較區(qū)域」，再分別對比actualDuration。
比如，對于下面的應(yīng)用：
<App>
<Sidebar />
<Content />
</App><Sidebar />和<Content />誰render更耗時？
此時可以用Profiler分別包裹這兩個組件：
<App>
<Profiler id="Sidebar" onRender={onRender}>
<Sidebar />
</Profiler>
<Profiler id="Content" onRender={onRender}>
<Content />
</Profiler>
</App>再分別在onRender中衡量actualDuration，值比較高的區(qū)域render更耗時。
這種方式定制性比較高。如果想更直觀比較哪些組件render更耗時，可以使用React Dev Tools中Profiler面板的火炬圖。
總結(jié)
Profiler是React內(nèi)置的性能分析組件，用于度量其包裹的子樹的渲染性能。
最后說個有意思的細(xì)節(jié) —— 在官網(wǎng)Profiler部分[2]中只介紹了Profiler有onRender這個回調(diào)。
從Profiler源碼看，他還存在：
- onCommit回調(diào)
- onPostCommit回調(diào)
- onNestedUpdateScheduled回調(diào)
不知道為什么，他們沒有在文檔中提及。
參考資料
[1]why-did-you-render:https://www.npmjs.com/package/@welldone-software/why-did-you-render。
[2]官網(wǎng)Profiler部分:https://react.dev/reference/react/Profiler。
