React不能將useMemo設置為默認方法原因詳解

Posted on by

本文的起因😗

有朋友在評論區裡問：那為什麼 React 不直接默認使用這種 memorized 的東東呢？讓全部東西都緩存~減少渲染

嗯嗯？我剛打算去截圖，結果發現好多評論給刪掉瞭？？？🤨我那時還打瞭好長幾段回答讀者的問題……總共 五十多個評論，應該是有包括那些的… 從消息界面裡找到瞭一部分

大概就是直接讓所有的東西都 默認套上一層 useMemo (or 其他的xxx) 不就好瞭？
還真不行~

你能學到 / 本文框架

memo

const MyComponent = React.memo(function MyComponent(props) {
  /* 使用 props 渲染 */
});

React.memo 為高階組件。 如果你的組件在相同 props 的情況下渲染相同的結果，那麼你可以通過將其包裝在 React.memo 中調用，以此通過記憶組件渲染結果的方式來提高組件的性能表現。這意味著在這種情況下，React 將跳過渲染組件的操作並直接復用最近一次渲染的結果。

useMemo

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

把待執行函數和依賴項數組作為參數傳入 useMemo，返回一個 memoized 值。它僅會在某個依賴項改變時才重新計算 memoized 值。這種優化有助於避免在每次渲染時都進行高開銷的計算。
如果沒有提供依賴項數組，useMemo 在每次渲染時都會計算新的值。

useCallback

const memoizedCallback = useCallback(
  () => {
    doSomething(a, b);
  },
  [a, b],
);

把回調函數及依賴項數組作為參數傳入 useCallback，它將返回該回調函數的 memoized 版本，該回調函數僅在某個依賴項改變時才會更新。

當你把回調函數傳遞給經過優化的並使用引用相等性去避免非必要渲染（例如 shouldComponentUpdate）的子組件時，它將非常有用。

useCallback(fn, deps) 相當於 useMemo(() => fn, deps)。

網上關於React 性能優化的教程🤔

看起來啊，這兩個 Hooks 確實是可以通過避免非必要渲染，減少我們頁面的重繪，從而提高性能
網上有很多 React 的教程，其中提到性能優化時，也都會告訴你，用 React 開發者工具檢測什麼組件出現瞭太多次的渲染，以及是什麼導致的，那就在那上面包裹一個 useMemo

“用它！用它！”

但有沒有想過一個問題：這種特性，為什麼 React 不直接在所有相關的東西裡面都內部 實現呢？或者說為什麼不把他們搞成 default 呢？

不要把它當作語義上的保證

官方文檔告訴你：

你可以把 useMemo 作為性能優化的手段，但不要把它當成語義上的保證。將來，React 可能會選擇“遺忘”以前的一些 memoized 值，並在下次渲染時重新計算它們，比如為離屏組件釋放內存。先編寫在沒有 useMemo 的情況下也可以執行的代碼 —— 之後再在你的代碼中添加 useMemo，以達到優化性能的目的。

它本身也不是那麼地能保證嘎嘎**好用 **

為什麼可能更糟糕🎂

比如現在有一個方法

const edit = id => {
  setList(list => list.filter(idx => idx !== id))
}

我們“常規”地用 useCallback 優化一下

const edit = useCallback(id => {
  setList(list => list.filter(idx => idx !== id))
}, [])

每行代碼的成本😶

實際上，上面優化 後的代碼實際上就相當於這樣：

const edit = id => {
  setList(list => list.filter(idx => idx !== id))
}
const memorizedEdit = useCallback(edit, []) //  多瞭這一行

可以看作是多瞭一些東西：

  • 一個數組：deps
  • 調用 useCallback
  • 定義多一個函數，Javascript 在每次渲染的時候都會給函數定義分配內存，並且 useCallback 這個方法會讓其需要更多的內存分配

啊，當然裡面這個 deps 數組可以用 useMemo 將其 memorize ，但是~ 這會導致到處都是 useMemo，以及 useMemo 也會像上面 useCallback 一樣帶來一些新的東西…

deps 空間成本以及其帶來的時間成本

前面說到瞭使用這些肯定會帶有dependency list，它是一個數組，當然有空間成本。除此之外，每次render時自然還要將數組中的每一個值進行一個比對的行為，檢查是否有新的變化
遍歷數組，這也是一個時間復雜度為O(N)的過程~

成本和收獲相近時👻

實際上，哪怕成本和收獲相近，那不就是他們其實啥也沒幹？ 但你的代碼大小、復雜度等等卻是實實在在的增加瞭~ 甚至會進一步導致更容易寫出糟糕的代碼

日常開發的“性能優化”🚀

現在大部分日常項目中的“計算”，對於現代瀏覽器、電腦硬件等，都是非常微乎其微的。實際上，你可能並不需要這些“優化”。所以我建議大部分時候，先讓能達成最終需求效果的代碼跑成功瞭，遇到性能瓶頸瞭再添加這些優化的手段

小結🍱

也就是說**，性能優化並不是 完全免費 的，這是絕對有成本的，甚至有時帶來的好處不能抵消成本。
所以你需要做的是負責任地進行優化**

選擇優化

demo 例子

先來看看這個例子

import { useState } from "react";
export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<div>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事瞭
	return <p>so big to make it render slowly</p>;
}

隨著 text 的變化，每一次都要渲染非常難辦的 <Big/>

哎不管他到底大不大，總之render不想老是帶ta玩就完事瞭

當然，你可能第一個想到的就是 套個 memo 就完瞭~

但是，有沒有其他選擇呢？即剩下 memo 的成本，又能對其進行性能優化?

抽離組件，帶走 state🍖

實際上，隻有這兩行代碼在意 text不是嗎

<input value={text} onChange={e => setText(e.target.value)} />
<p>{text}</p>

我們將它倆抽離出來為一個組件Small，把 state 放進去就好瞭~

export default function App() {
	return (
		<div>
			<Small />
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事瞭
	return <p>so big to make it render slowly</p>;
}
function Small() {
	let [text, setText] = useState("zhou")
  return (
    <>
      <input value={text} onChange={e => setText(e.target.value)} />
      <p>{text}</p>
    </>
  )
}

現在好瞭，當 text 改變，自然就隻有 Small會重新渲染，討厭的<Big/>就不會老來騷擾瞭，good~

抽離組件， 孤立 Big🥙

有時候，在意text的是父組件，但其中的“消耗大”的子組件其實並不在意，那該怎麼將 care 的和 不 care 的隔離？

import { useState } from "react";
export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<div data-text = {text}>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			<Big />
		</div>
	);
}
function Big() {
	// ... 很大很麻煩就完事瞭
	return <p>so big to make it render slowly</p>;
}

看起來沒辦法隻將 在意state的部分抽離出來，讓其帶走state瞭… 那我們直接把不在意的孤立瞭不就好瞭~

export default function App() {
  let [text, setText] = useState("zhou")
	return (
		<TextAbout>
			<Big />
		</TextAbout>
	);
}
function Big() {
	// ... 很大很麻煩就完事瞭
	return <p>so big to make it render slowly</p>;
}
function TextAbout({children}){
	let [text, setText] = useState("zhou")
	return (
		<div data-text={text}>
			<input value={text} onChange={e => setText(e.target.value)} />
			<p>{text}</p>
			{children}
		</div>
	)
}

我們將text相關的父組件和子組件全部拿出來，作為TextAbout。不關心text且麻煩的Big留在App中，作為children屬性傳入TextAbout中。當text變化，TextAbout會重新渲染，但是其中保留的仍是之前從App中拿到的children屬性。

好慘的 <Big/>，被狠狠地孤立瞭，在裡面，但不完全在裡面 [doge]

小結

當你有使用memo等東東的想法時，你可以先試試不用他們~

那到底應該什麼時候用🍗

前面我們說到瞭，需要負責任地使用

什麼叫負責任地使用🥂

你怎麼樣判斷付出的成本比收獲的少？或許你可以好好地 測量 一下~

React 官方的測量API Profiler

API Profiler

Profiler 測量一個 React 應用多久渲染一次以及渲染一次的“代價”。 它的目的是識別出應用中渲染較慢的部分，或是可以使用類似 memoization 優化的部分，並從相關優化中獲益。

具體用法看文檔啦，搬一大段到文章上也沒意思~

或許還有其他測量方法，自行查閱~

又或者你是完完全全地保證這個組件的渲染真的非常需要時間，能不渲染絕不再次渲染~比如一些很大的動畫？可視化的大屏？巨大圖表？（我猜的 [doge])

或許真的有需要😏

真正“備忘錄”的作用🍤

這個點其實原生 JS 也是一樣的道理：一段代碼執行比較耗時，但是執行的結果經常用到，那就用一個東西將其結果存起來，再用到的時候直接取~ 以空間換時間–

其實 React 這幾個 API 某種程度也是有 空間換時間 的思想

大概是這樣

const ans = useMemo(() => calculate(a, b), [a, b]);

有時需要“引用相等”🍚

寫 JS 的都知道的：

{} !== {}
[] !== []
()=>{} !== ()=>{}

以上都為 true~
這意味著useEffect等hook中比對deps時會出現：他完全一樣，但是 React 不認為他一樣

React 中用的是Object.is，但是對於這些情況，和===差不多

這時可能就需要用useCallback或者useMemo來助你一臂之力~

總結⛵

本文從 memo等api 的收獲和成本講起，（其實沒提到的如PureComponent 後者shouldComponentUpdate等類似“阻止渲染 & 減少渲染次數”功能的都有差不多的道理~）
細說瞭一下成本，以及一些可能不需要這些成本也能進行的優化方法，粗略地講瞭一下可能真的有需求要用的場景，大概地講述瞭一些不能一把梭這些玩意的論點~

其實最強力的論點就是：為什麼 React 不把這些搞成 默認方法😛

關於是否使用這些，或許可以用一句話來總結：

如果沒有性能瓶頸，那就建議不用，大部分項目你可能並不需要考慮以阻止 React 的渲染來提高性能 —— 甚至可以說如果你不能保證收獲比成本大的“多”，那就盡量不用。

其實這上面這句話也藏著性能優化的原則之一：不要過早優化

參考文檔

memorize

React.memo

useCallback

useMemo

Profiler

Hooks FAQ

更多關於React不設置useMemo默認方法的資料請關註WalkonNet其它相關文章！

推薦閱讀：