React不能將useMemo設(shè)置為默認(rèn)方法原因詳解
本文的起因??
有朋友在評(píng)論區(qū)里問:那為什么 React 不直接默認(rèn)使用這種 memorized
的東東呢?讓全部東西都緩存~減少渲染
嗯嗯?我剛打算去截圖,結(jié)果發(fā)現(xiàn)好多評(píng)論給刪掉了?????我那時(shí)還打了好長幾段回答讀者的問題......總共 五十多個(gè)評(píng)論,應(yīng)該是有包括那些的... 從消息界面里找到了一部分
大概就是直接讓所有的東西都 默認(rèn)套上一層 useMemo (or 其他的xxx)
不就好了?
還真不行~
你能學(xué)到 / 本文框架
memo
const MyComponent = React.memo(function MyComponent(props) { /* 使用 props 渲染 */ });
React.memo 為高階組件。 如果你的組件在相同 props 的情況下渲染相同的結(jié)果,那么你可以通過將其包裝在 React.memo 中調(diào)用,以此通過記憶組件渲染結(jié)果的方式來提高組件的性能表現(xiàn)。這意味著在這種情況下,React 將跳過渲染組件的操作并直接復(fù)用最近一次渲染的結(jié)果。
useMemo
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
把待執(zhí)行函數(shù)和依賴項(xiàng)數(shù)組作為參數(shù)傳入 useMemo
,返回一個(gè) memoized 值。它僅會(huì)在某個(gè)依賴項(xiàng)改變時(shí)才重新計(jì)算 memoized
值。這種優(yōu)化有助于避免在每次渲染時(shí)都進(jìn)行高開銷的計(jì)算。
如果沒有提供依賴項(xiàng)數(shù)組,useMemo 在每次渲染時(shí)都會(huì)計(jì)算新的值。
useCallback
const memoizedCallback = useCallback( () => { doSomething(a, b); }, [a, b], );
把回調(diào)函數(shù)及依賴項(xiàng)數(shù)組作為參數(shù)傳入 useCallback
,它將返回該回調(diào)函數(shù)的 memoized 版本,該回調(diào)函數(shù)僅在某個(gè)依賴項(xiàng)改變時(shí)才會(huì)更新。
當(dāng)你把回調(diào)函數(shù)傳遞給經(jīng)過優(yōu)化的并使用引用相等性去避免非必要渲染(例如 shouldComponentUpdate)的子組件時(shí),它將非常有用。
useCallback(fn, deps)
相當(dāng)于 useMemo(() => fn, deps)
。
網(wǎng)上關(guān)于React 性能優(yōu)化的教程??
看起來啊,這兩個(gè) Hooks 確實(shí)是可以通過避免非必要渲染,減少我們頁面的重繪,從而提高性能
網(wǎng)上有很多 React 的教程,其中提到性能優(yōu)化時(shí),也都會(huì)告訴你,用 React 開發(fā)者工具檢測(cè)什么組件出現(xiàn)了太多次的渲染,以及是什么導(dǎo)致的,那就在那上面包裹一個(gè) useMemo
“用它!用它!”
但有沒有想過一個(gè)問題:這種特性,為什么 React 不直接在所有相關(guān)的東西里面都內(nèi)部 實(shí)現(xiàn)呢?或者說為什么不把他們搞成 default 呢?
不要把它當(dāng)作語義上的保證
官方文檔告訴你:
你可以把 useMemo 作為性能優(yōu)化的手段,但不要把它當(dāng)成語義上的保證。將來,React 可能會(huì)選擇“遺忘”以前的一些 memoized 值,并在下次渲染時(shí)重新計(jì)算它們,比如為離屏組件釋放內(nèi)存。先編寫在沒有 useMemo 的情況下也可以執(zhí)行的代碼 —— 之后再在你的代碼中添加 useMemo,以達(dá)到優(yōu)化性能的目的。
它本身也不是那么地能保證嘎嘎**好用 **
為什么可能更糟糕??
比如現(xiàn)在有一個(gè)方法
const edit = id => { setList(list => list.filter(idx => idx !== id)) }
我們“常規(guī)”地用 useCallback 優(yōu)化一下
const edit = useCallback(id => { setList(list => list.filter(idx => idx !== id)) }, [])
每行代碼的成本??
實(shí)際上,上面優(yōu)化 后的代碼實(shí)際上就相當(dāng)于這樣:
const edit = id => { setList(list => list.filter(idx => idx !== id)) } const memorizedEdit = useCallback(edit, []) // 多了這一行
可以看作是多了一些東西:
- 一個(gè)數(shù)組:
deps
- 調(diào)用
useCallback
- 定義多一個(gè)函數(shù),
Javascript
在每次渲染的時(shí)候都會(huì)給函數(shù)定義分配內(nèi)存,并且useCallback
這個(gè)方法會(huì)讓其需要更多的內(nèi)存分配
啊,當(dāng)然里面這個(gè) deps
數(shù)組可以用 useMemo
將其 memorize
,但是~ 這會(huì)導(dǎo)致到處都是 useMemo
,以及 useMemo
也會(huì)像上面 useCallback
一樣帶來一些新的東西...
deps 空間成本以及其帶來的時(shí)間成本
前面說到了使用這些肯定會(huì)帶有dependency list
,它是一個(gè)數(shù)組,當(dāng)然有空間成本。除此之外,每次render
時(shí)自然還要將數(shù)組中的每一個(gè)值進(jìn)行一個(gè)比對(duì)的行為,檢查是否有新的變化
遍歷數(shù)組,這也是一個(gè)時(shí)間復(fù)雜度為O(N)的過程~
成本和收獲相近時(shí)??
實(shí)際上,哪怕成本和收獲相近,那不就是他們其實(shí)啥也沒干? 但你的代碼大小、復(fù)雜度等等卻是實(shí)實(shí)在在的增加了~ 甚至?xí)M(jìn)一步導(dǎo)致更容易寫出糟糕的代碼
日常開發(fā)的“性能優(yōu)化”??
現(xiàn)在大部分日常項(xiàng)目中的“計(jì)算”,對(duì)于現(xiàn)代瀏覽器、電腦硬件等,都是非常微乎其微的。實(shí)際上,你可能并不需要這些“優(yōu)化”。所以我建議大部分時(shí)候,先讓能達(dá)成最終需求效果的代碼跑成功了,遇到性能瓶頸了再添加這些優(yōu)化的手段
小結(jié)??
也就是說**,性能優(yōu)化并不是 完全免費(fèi) 的,這是絕對(duì)有成本的,甚至有時(shí)帶來的好處不能抵消成本。
所以你需要做的是負(fù)責(zé)任地進(jìn)行優(yōu)化**
選擇優(yōu)化
demo 例子
先來看看這個(gè)例子
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玩就完事了
當(dāng)然,你可能第一個(gè)想到的就是 套個(gè) memo 就完了~
但是,有沒有其他選擇呢?即剩下 memo 的成本,又能對(duì)其進(jìn)行性能優(yōu)化?
抽離組件,帶走 state??
實(shí)際上,只有這兩行代碼在意 text
不是嗎
<input value={text} onChange={e => setText(e.target.value)} /> <p>{text}</p>
我們將它倆抽離出來為一個(gè)組件Small
,把 state 放進(jìn)去就好了~
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> </> ) }
現(xiàn)在好了,當(dāng) text
改變,自然就只有 Small
會(huì)重新渲染,討厭的<Big/>
就不會(huì)老來騷擾了,good~
抽離組件, 孤立 Big??
有時(shí)候,在意text
的是父組件,但其中的“消耗大”的子組件其實(shí)并不在意,那該怎么將 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
相關(guān)的父組件和子組件全部拿出來,作為TextAbout
。不關(guān)心text
且麻煩的Big
留在App
中,作為children
屬性傳入TextAbout
中。當(dāng)text
變化,TextAbout
會(huì)重新渲染,但是其中保留的仍是之前從App
中拿到的children
屬性。
好慘的 <Big/>
,被狠狠地孤立了,在里面,但不完全在里面 [doge]
小結(jié)
當(dāng)你有使用memo
等東東的想法時(shí),你可以先試試不用他們~
那到底應(yīng)該什么時(shí)候用??
前面我們說到了,需要負(fù)責(zé)任地使用
什么叫負(fù)責(zé)任地使用??
你怎么樣判斷付出的成本比收獲的少?或許你可以好好地 測(cè)量 一下~
React 官方的測(cè)量API Profiler
API Profiler
Profiler 測(cè)量一個(gè) React 應(yīng)用多久渲染一次以及渲染一次的“代價(jià)”。 它的目的是識(shí)別出應(yīng)用中渲染較慢的部分,或是可以使用類似 memoization 優(yōu)化的部分,并從相關(guān)優(yōu)化中獲益。
具體用法看文檔啦,搬一大段到文章上也沒意思~
或許還有其他測(cè)量方法,自行查閱~
又或者你是完完全全地保證這個(gè)組件的渲染真的非常需要時(shí)間,能不渲染絕不再次渲染~比如一些很大的動(dòng)畫?可視化的大屏?巨大圖表?(我猜的 [doge])
或許真的有需要??
真正“備忘錄”的作用??
這個(gè)點(diǎn)其實(shí)原生 JS 也是一樣的道理:一段代碼執(zhí)行比較耗時(shí),但是執(zhí)行的結(jié)果經(jīng)常用到,那就用一個(gè)東西將其結(jié)果存起來,再用到的時(shí)候直接取~ 以空間換時(shí)間--
其實(shí) React 這幾個(gè) API 某種程度也是有 空間換時(shí)間 的思想
大概是這樣
const ans = useMemo(() => calculate(a, b), [a, b]);
有時(shí)需要“引用相等”??
寫 JS 的都知道的:
{} !== {}
[] !== []
()=>{} !== ()=>{}
以上都為 true~
這意味著useEffect
等hook
中比對(duì)deps
時(shí)會(huì)出現(xiàn):他完全一樣,但是 React 不認(rèn)為他一樣
React 中用的是Object.is
,但是對(duì)于這些情況,和===
差不多
這時(shí)可能就需要用useCallback
或者useMemo
來助你一臂之力~
總結(jié)?
本文從 memo等api 的收獲和成本講起,(其實(shí)沒提到的如PureComponent
后者shouldComponentUpdate
等類似“阻止渲染 & 減少渲染次數(shù)”功能的都有差不多的道理~)
細(xì)說了一下成本,以及一些可能不需要這些成本也能進(jìn)行的優(yōu)化方法,粗略地講了一下可能真的有需求要用的場(chǎng)景,大概地講述了一些不能一把梭這些玩意的論點(diǎn)~
其實(shí)最強(qiáng)力的論點(diǎn)就是:為什么 React 不把這些搞成 默認(rèn)方法??
關(guān)于是否使用這些,或許可以用一句話來總結(jié):
如果沒有性能瓶頸,那就建議不用,大部分項(xiàng)目你可能并不需要考慮以阻止 React 的渲染來提高性能 —— 甚至可以說如果你不能保證收獲比成本大的“多”,那就盡量不用。
其實(shí)這上面這句話也藏著性能優(yōu)化的原則之一:不要過早優(yōu)化
參考文檔
更多關(guān)于React不設(shè)置useMemo默認(rèn)方法的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
react實(shí)現(xiàn)全局組件確認(rèn)彈窗
這篇文章主要為大家詳細(xì)介紹了react實(shí)現(xiàn)全局組件確認(rèn)彈窗,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-08-08ReactNative實(shí)現(xiàn)的橫向滑動(dòng)條效果
本文介紹了ReactNative實(shí)現(xiàn)的橫向滑動(dòng)條效果,本文結(jié)合示例代碼給大家介紹的非常詳細(xì),補(bǔ)充介紹了ReactNative基于寬度變化實(shí)現(xiàn)的動(dòng)畫效果,感興趣的朋友跟隨小編一起看看吧2024-02-02Jira 任務(wù)管理系統(tǒng)項(xiàng)目總結(jié)講解
這篇文章主要為大家介紹了Jira 任務(wù)管理系統(tǒng)項(xiàng)目總結(jié)講解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-08-08詳解使用React.memo()來優(yōu)化函數(shù)組件的性能
本文講述了開發(fā)React應(yīng)用時(shí)如何使用shouldComponentUpdate生命周期函數(shù)以及PureComponent去避免類組件進(jìn)行無用的重渲染,以及如何使用最新的React.memo API去優(yōu)化函數(shù)組件的性能2019-03-03react使用axios實(shí)現(xiàn)上傳下載功能
這篇文章主要為大家詳細(xì)介紹了react使用axios實(shí)現(xiàn)上傳下載功能,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-08-08React native ListView 增加頂部下拉刷新和底下點(diǎn)擊刷新示例
這篇文章主要介紹了React native ListView 增加頂部下拉刷新和底下點(diǎn)擊刷新示例,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-04-04react antd表格中渲染一張或多張圖片的實(shí)例
這篇文章主要介紹了react antd表格中渲染一張或多張圖片的實(shí)例,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-10-10