想要升職加薪就要努力學(xué)習(xí)這篇React不能將useMemo設(shè)置為默認(rèn)方法原因詳解，

　　很多朋友都建議可以用 React 這樣就不直接默認(rèn)使用這種memorized呢？還可以讓所有資料都緩存~減少渲染

　　話不多說(shuō)，直接上。大概就是直接讓所有的東西都 默認(rèn)套上一層useMemo (or 其他的xxx)不就好了？

　　還真不行~

　　你能學(xué)到 / 本文框架

　　memo

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

　　React.memo 為高階組件。 如果你的組件在相同 props 的情況下渲染相同的結(jié)果，那么你可以通過(guò)將其包裝在 React.memo 中調(diào)用，以此通過(guò)記憶組件渲染結(jié)果的方式來(lái)提高組件的性能表現(xiàn)。這意味著在這種情況下，React 將跳過(guò)渲染組件的操作并直接復(fù)用最近一次渲染的結(jié)果。

　　useMemo

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

　　把待執(zhí)行函數(shù)和依賴(lài)項(xiàng)數(shù)組作為參數(shù)傳入useMemo，返回一個(gè) memoized 值。它僅會(huì)在某個(gè)依賴(lài)項(xiàng)改變時(shí)才重新計(jì)算memoized值。這種優(yōu)化有助于避免在每次渲染時(shí)都進(jìn)行高開(kāi)銷(xiāo)的計(jì)算。

　　如果沒(méi)有提供依賴(lài)項(xiàng)數(shù)組，useMemo 在每次渲染時(shí)都會(huì)計(jì)算新的值。

　　useCallback

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

　　把回調(diào)函數(shù)及依賴(lài)項(xiàng)數(shù)組作為參數(shù)傳入useCallback，它將返回該回調(diào)函數(shù)的 memoized 版本，該回調(diào)函數(shù)僅在某個(gè)依賴(lài)項(xiàng)改變時(shí)才會(huì)更新。

　　當(dāng)你把回調(diào)函數(shù)傳遞給經(jīng)過(guò)優(yōu)化的并使用引用相等性去避免非必要渲染（例如 shouldComponentUpdate）的子組件時(shí)，它將非常有用。

　　useCallback(fn, deps)相當(dāng)于useMemo(() => fn, deps)。

　　網(wǎng)上關(guān)于React 性能優(yōu)化的教程????

　　看起來(lái)啊，這兩個(gè) Hooks 確實(shí)是可以通過(guò)避免非必要渲染，減少我們頁(yè)面的重繪，從而提高性能

　　網(wǎng)上有很多 React 的教程，其中提到性能優(yōu)化時(shí)，也都會(huì)告訴你，用 React 開(kāi)發(fā)者工具檢測(cè)什么組件出現(xiàn)了太多次的渲染，以及是什么導(dǎo)致的，那就在那上面包裹一個(gè) useMemo

　　“用它！用它！”

　　但有沒(méi)有想過(guò)一個(gè)問(wèn)題：這種特性，為什么 React 不直接在所有相關(guān)的東西里面都內(nèi)部 實(shí)現(xiàn)呢？或者說(shuō)為什么不把他們搞成 default 呢？

　　不要把它當(dāng)作語(yǔ)義上的保證

　　官方文檔告訴你：

　　你可以把 useMemo 作為性能優(yōu)化的手段，但不要把它當(dāng)成語(yǔ)義上的保證。將來(lái)，React 可能會(huì)選擇“遺忘”以前的一些 memoized 值，并在下次渲染時(shí)重新計(jì)算它們，比如為離屏組件釋放內(nèi)存。先編寫(xiě)在沒(mé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一樣帶來(lái)一些新的東西...

　　deps 空間成本以及其帶來(lái)的時(shí)間成本

　　前面說(shuō)到了使用這些肯定會(huì)帶有dependency list，它是一個(gè)數(shù)組，當(dāng)然有空間成本。除此之外，每次render時(shí)自然還要將數(shù)組中的每一個(gè)值進(jìn)行一個(gè)比對(duì)的行為，檢查是否有新的變化

　　遍歷數(shù)組，這也是一個(gè)時(shí)間復(fù)雜度為O(N)的過(guò)程~

　　成本和收獲相近時(shí)????

　　實(shí)際上，哪怕成本和收獲相近，那不就是他們其實(shí)啥也沒(méi)干？ 但你的代碼大小、復(fù)雜度等等卻是實(shí)實(shí)在在的增加了~ 甚至?xí)M(jìn)一步導(dǎo)致更容易寫(xiě)出糟糕的代碼

　　日常開(kāi)發(fā)的“性能優(yōu)化”????

　　現(xiàn)在大部分日常項(xiàng)目中的“計(jì)算”，對(duì)于現(xiàn)代瀏覽器、電腦硬件等，都是非常微乎其微的。實(shí)際上，你可能并不需要這些“優(yōu)化”。所以我建議大部分時(shí)候，先讓能達(dá)成最終需求效果的代碼跑成功了，遇到性能瓶頸了再添加這些優(yōu)化的手段

　　小結(jié)????

　　雖然是有優(yōu)化，但成本太大了，甚至有時(shí)帶來(lái)的好處不能抵消成本。

　　這也是我們責(zé)任要優(yōu)化

　　選擇優(yōu)化

　　我們一起先看看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玩，就是了

　　當(dāng)然，你可能第一個(gè)想到的就是 套個(gè) memo 就完了~

　　但是，有沒(méi)有其他選擇呢？即剩下 memo 的成本，又能對(duì)其進(jìn)行性能優(yōu)化?

　　抽離組件，帶走 state????

　　實(shí)際上，只有這兩行代碼在意text不是嗎

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

　　我們將它倆抽離出來(lái)為一個(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ì)老來(lái)騷擾了，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>;
　　}

　　看起來(lái)沒(méi)辦法只將 在意state的部分抽離出來(lái)，讓其帶走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)的父組件和子組件全部拿出來(lái)，作為T(mén)extAbout。不關(guān)心text且麻煩的Big留在App中，作為children屬性傳入TextAbout中。當(dāng)text變化，TextAbout會(huì)重新渲染，但是其中保留的仍是之前從App中拿到的children屬性。

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

　　小結(jié)

　　當(dāng)你有使用memo等東東的想法時(shí)，你可以先試試不用他們~

　　那到底應(yīng)該什么時(shí)候用????

　　前面我們說(shuō)到了，需要負(fù)責(zé)任地使用

　　什么叫負(fù)責(zé)任地使用????

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

　　React 官方的測(cè)量API Profiler

　　APIProfiler

　　Profiler 測(cè)量一個(gè) React 應(yīng)用多久渲染一次以及渲染一次的“代價(jià)”。 它的目的是識(shí)別出應(yīng)用中渲染較慢的部分，或是可以使用類(lèi)似 memoization 優(yōu)化的部分，并從相關(guān)優(yōu)化中獲益。

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

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

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

　　或許真的有需要????

　　真正“備忘錄”的作用????

　　這個(gè)點(diǎn)其實(shí)原生 JS 也是一樣的道理：一段代碼執(zhí)行比較耗時(shí)，但是執(zhí)行的結(jié)果經(jīng)常用到，那就用一個(gè)東西將其結(jié)果存起來(lái)，再用到的時(shí)候直接取~ 以空間換時(shí)間--

　　其實(shí) React 這幾個(gè) API 某種程度也是有 空間換時(shí)間 的思想

　　大概是這樣

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

　　有時(shí)需要“引用相等”????

　　寫(xiě) JS 的都知道的：

　　{} !== {}

　　[] !== []

　　()=>{} !== ()=>{}

　　以上都為 true~

　　這意味著useEffect等hook中比對(duì)deps時(shí)會(huì)出現(xiàn)：他完全一樣，但是 React 不認(rèn)為他一樣

　　React 中用的是Object.is，但是對(duì)于這些情況，和===差不多

　　用seCallback或者useMemo這時(shí)候就是必須添加進(jìn)來(lái)的。

　　總結(jié)?

　　本文從 memo等api 的收獲和成本講起，（其實(shí)沒(méi)提到的如PureComponent后者shouldComponentUpdate等類(lèi)似“阻止渲染 & 減少渲染次數(shù)”功能的都有差不多的道理~）

　　細(xì)說(shuō)了一下成本，以及一些可能不需要這些成本也能進(jìn)行的優(yōu)化方法，粗略地講了一下可能真的有需求要用的場(chǎng)景，大概地講述了一些不能一把梭這些玩意的論點(diǎn)~

　　其實(shí)最強(qiáng)力的論點(diǎn)就是：為什么 React 不把這些搞成 默認(rèn)方法????

　　關(guān)于是否使用這些，或許可以用一句話來(lái)總結(jié)：

　　這個(gè)適用的就是有性能瓶頸用，大部分項(xiàng)目你可能并不需要考慮以阻止 React 的渲染來(lái)提高性能 —— 但誰(shuí)也無(wú)法保證，能收獲比成本大的“多”，那就盡量不用。

　　總結(jié)一句話就是：不要過(guò)早優(yōu)化