兩年過去了，React Forget 涼了么？

作者：卡頌 2023-10-26 06:51:29

現(xiàn)在2年過去了，我們很少聽到React Forget的進(jìn)展，黃玄也離開「React 團(tuán)隊(duì)」了。這讓我們不禁要問，React Forget涼了么？本文會聊聊React Forget當(dāng)前的進(jìn)展、接下來的發(fā)展方向，以及他的工作原理。

大家好，我卡頌。

在 2 年前的React Conf 2021[1]，黃玄第一次介紹了React Forget，這是個(gè)「可以生成等效于 useMemo、React.memo」的編譯器（可以簡單理解為，有了它，開發(fā)者不需要考慮React項(xiàng)目的性能優(yōu)化了）。

由于React獨(dú)特的架構(gòu)（全局更新），「React 性能優(yōu)化」一直讓開發(fā)者頭疼，這里主要有兩個(gè)問題：

很多開發(fā)者不知道如何正確使用性能優(yōu)化API，甚至有人認(rèn)為FC（函數(shù)組件）中所有函數(shù)都應(yīng)該包裹在useCallback中
即使寫出性能優(yōu)秀的項(xiàng)目，隨著需求迭代，新增的代碼很可能破壞之前的優(yōu)化效果

所以，React Forget的愿景一經(jīng)宣傳，就受到社區(qū)極大的關(guān)注。從React Conf 2021油管播放量來看，React Forget演講占了所有 19 個(gè)演講總播放量的 1/4（當(dāng)然，也可能是因?yàn)辄S玄長得帥）。

現(xiàn)在2年過去了，我們很少聽到React Forget的進(jìn)展，黃玄也離開「React 團(tuán)隊(duì)」了。這讓我們不禁要問，React Forget涼了么？

本文會聊聊React Forget當(dāng)前的進(jìn)展、接下來的發(fā)展方向，以及他的工作原理。

React Forget 涼了么？

首先要明確的是，React Forget并沒有涼，相反，他正在穩(wěn)定迭代。

根據(jù)React團(tuán)隊(duì)成員「Mofei Zhang」在React Advanced London 2023[2]的演講指出，「React 團(tuán)隊(duì)」出品的所有產(chǎn)品，都會經(jīng)歷 5 個(gè)階段：

理念驗(yàn)證
產(chǎn)品實(shí)現(xiàn)
Meta內(nèi)部挑選業(yè)務(wù)線，小范圍使用
推廣到Meta其他業(yè)務(wù)線
發(fā)布開源版本

當(dāng)前React Forget正處在階段 3，已經(jīng)在下述兩個(gè)產(chǎn)品的生產(chǎn)環(huán)境投入使用：

quest store[3]，Meta旗下VR產(chǎn)品的應(yīng)用商店，基于React Native開發(fā)。
instagram[4]，web項(xiàng)目，基于React DOM開發(fā)。

效果如何呢？以quest store舉例。下圖是quest store的產(chǎn)品詳情頁（由React Native實(shí)現(xiàn)）：

quest store產(chǎn)品詳情頁

可以看到，這是個(gè)左右布局的項(xiàng)目，點(diǎn)擊左側(cè)Tab右邊會有相應(yīng)變化。

下圖是使用React Forget前，通過React Profiler測量的「點(diǎn)擊左側(cè) Tab 觸發(fā)更新」后的更新火炬圖，其中：

每個(gè)小塊代表一個(gè)組件。
綠色小塊代表「觸發(fā)本次更新后，會 render 的組件」。
灰色小塊代表「觸發(fā)本次更新后，不會 render 的組件」（命中性能優(yōu)化）。

顯然，當(dāng)觸發(fā)更新后，灰色小塊越多，項(xiàng)目性能越好。

當(dāng)項(xiàng)目經(jīng)過React Forget編譯優(yōu)化后，執(zhí)行同樣操作的更新火炬圖如下（其中紅框內(nèi)是優(yōu)化的部分。也就是說，經(jīng)過優(yōu)化后，觸發(fā)同樣的操作，紅框內(nèi)的組件都不會render了）：

這個(gè)優(yōu)化效果有多好呢？數(shù)值如下：

「切換 Tab 操作」的響應(yīng)速度提高 150%
頁面加載速度提高 4-12%

這里需要指出的是，經(jīng)由React Forget生成的優(yōu)化代碼等效于useMemo、React.memo這樣的「緩存 API」，而這些API主要是減少rerender過程中render的組件數(shù)量。

雖然「頁面加載」主要是首屏渲染（mount），此時(shí)這些緩存API發(fā)揮不了作用。但要完成頁面加載，很多組件是需要rerender的。舉個(gè)例子，對于列表的渲染，包括兩個(gè)步驟：

首屏渲染（mount），渲染空列表
獲取到數(shù)據(jù)后，渲染（rerender）包含數(shù)據(jù)的列表

所以，React Forget通過提高rerender速度，提高了頁面加載速度。

有同學(xué)可能會質(zhì)疑 —— 是這個(gè)項(xiàng)目本身做的優(yōu)化太少了，才顯得優(yōu)化效果好吧？

首先，我們可以從優(yōu)化前的火炬圖的灰色部分（下圖綠框內(nèi)）看出，項(xiàng)目是經(jīng)過性能優(yōu)化的（否則應(yīng)該都是綠色小塊）：

但是，一個(gè)精心優(yōu)化過性能的React項(xiàng)目，就像撲克搭的城堡，任何風(fēng)吹草動都能讓優(yōu)化效果付之東流：

舉個(gè)例子，假設(shè)項(xiàng)目中有個(gè)很耗性能的組件ExpensiveCpn：

<ExpensiveCpn data={data}/>

你將ExpensiveCpn用React.memo包裹，將data用useMemo包裹，使得ExpensiveCpn非必要不render。

但是，團(tuán)隊(duì)其他成員接到需求，要給ExpensiveCpn增加個(gè)新props：

<ExpensiveCpn data={data} items={items}/>

由于新加的items props沒有用useMemo包裹，使得你的優(yōu)化失去效果（在復(fù)雜項(xiàng)目中，這種情況很常見）。

這就造成個(gè)悖論 —— 越是訪問量大、迭代頻繁、性能敏感的React項(xiàng)目，越難維持優(yōu)秀的性能。

從這個(gè)角度看，React Forget意義重大。

為什么迭代這么慢？

既然React Forget這么重要，為什么這兩年都沒啥消息呢？因?yàn)镴S作為動態(tài)語言語法太靈活，這極大增加了編譯器的開發(fā)難度。

根據(jù)從Chrome跳槽到「React 團(tuán)隊(duì)」的工程師「Sathya Gunasekaran」在React India 2023[5]演講中表示：在React Forget中實(shí)現(xiàn)Alias Analysis（別名分析）的難度，比在Chrome V8中還高。

好在React作為一種DSL，相比純JS實(shí)現(xiàn)的項(xiàng)目多了很多約束，使得靜態(tài)分析成為可能，比如：

React組件類似于純函數(shù)，這意味著相同的輸入（props）會獲得相同的輸出（JSX返回值）。

這使得每個(gè)組件都是一個(gè)可以獨(dú)立靜態(tài)分析的模塊（不需要考慮組件之間互相影響）。同時(shí)，React Forget也能并行分析多個(gè)組件。

FC（函數(shù)組件）的大規(guī)模使用。

Class Component中所有屬性、方法都綁定在this中，比如：

this.state
this.setState

開發(fā)者也能在this上掛載屬性，這種靈活性為靜態(tài)分析帶來很大難度。

隨著Hooks普及，新的React項(xiàng)目基本都基于FC實(shí)現(xiàn)，排除了this的影響。

Hooks。

「在 FC 中，以 use 開頭的函數(shù)都是 hook」，這條規(guī)定為靜態(tài)分析提供了線索，比如：

考慮副作用時(shí)，需要分析useEffect等
考慮狀態(tài)時(shí)，需要分析useState等

Immutable state（不可變狀態(tài)）。

狀態(tài)不可變，意味著編譯器不需要考慮下面這種情況：

function App() {
  const [num, update] = useState(0);
  num = 2;
  // ...
}

工作原理

需要明確一點(diǎn)，React Forget可以生成等效于useMemo、React.memo的代碼，并不意味著編譯后的代碼會出現(xiàn)上述API，而是會出現(xiàn)「效果等效于上述 API」的輔助代碼。

舉個(gè)例子，考慮下面的代碼。VideoTab組件會根據(jù)filter過濾出videos數(shù)組中「符合條件的 video」，并渲染頭組件（Heading）與列表組件（VideoList）：

function VideoTab({heading, videos, filter}) {
  const filterdList = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filterdList.push(video);
    }
  }
  if (filterdList.length === 0) {
    return <NoVideos />;
  }

  return (
    <>
      <Heading
        heading={heading}
        count={filterdList.length}
      />
      <VideoList videos={filterdList} />
    </>
  )
}

其中VideoList組件已經(jīng)被React.memo包裹：

const VideoList = React.memo(/* 省略 */)

當(dāng)前，雖然VideoList組件不依賴heading props，但是heading props變化也會導(dǎo)致VideoTab組件render（因?yàn)槊看蝦ender時(shí)都會生成新的filterdList）。為了優(yōu)化他，可以用useMemo包裹filterdList：

const filterdList = useMemo(() => {
  /* 省略 */
}, [videos, filter])

只有當(dāng)videos props或filter props變化時(shí)filterdList才會變化，就排除了heading props變化對VideoList組件的影響。

上述優(yōu)化是開發(fā)者手動性能優(yōu)化時(shí)會寫出的代碼。

如果交給React Forget，他會生成類似如下代碼。其中：

緩存被保存在名為useMemoCache的原生hook中。
if else起到了等效useMemo的作用。

function VideoTab({heading, videos, filter}) {
  const $ = useMemoCache(12);
  let filterdList;

  // 下面的if else起到了useMemo的效果
  if ($[0] !== videos || $[1] !== filter) {
    filterdList = [];

    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filterdList.push(video);
      }
    }

    $[0] = videos;
    $[1] = filter;
    $[2] = filterdList;
  } else {
    filterdList = $[2];
  }

  // ...省略
}

為什么不直接生成useMemo代碼呢？主要有兩個(gè)原因：

對于一個(gè)FC，大部分原生Hook的數(shù)據(jù)會保存在一條單向鏈表中（這也是「不能在條件語句中寫 Hooks」的原因），會占用更多內(nèi)存。

在React Forget生成的代碼中，緩存保存在useMemoCache中，通過觀察useMemoCache 的源碼[6]可以發(fā)現(xiàn)，在useMemoCache內(nèi)部，并不依賴單向鏈表保存數(shù)據(jù)。

這也意味著useMemoCache可以不遵守「不能在條件語句中寫 Hooks」這條規(guī)定。

useMemo內(nèi)部需要對依賴項(xiàng)進(jìn)行淺比較。

相比于淺比較，React Forget生成的if語句能直接被「JS 引擎」優(yōu)化，更高效。

雖然React Forget的工作原理看似簡單，但考慮到大量的邊界情況，實(shí)際實(shí)現(xiàn)起來會很復(fù)雜。

舉個(gè)例子，考慮下面的代碼：

function Parent({a, b}) {
  const x = [];
  x.push(a);

  return <Child x={x} />;
}

要優(yōu)化上述代碼很簡單，優(yōu)化結(jié)果如下（這里用「性能優(yōu)化 API」演示優(yōu)化效果，方便理解意思）：

function Parent({a, b}) {
  const x = useMemo(() => {
    const x = [];
    x.push(a);
    return x;
  }, [a])

  return <Child x={x} />;
}

現(xiàn)在，我們新增兩行代碼：

function Parent({a, b}) {
  const x = [];
  x.push(a);

  // 下面兩行是新增代碼
  const y = x;
  y.push(b);

  return <Child x={x} />;
}

按照優(yōu)化邏輯，下面是優(yōu)化后的代碼：

function Parent({a, b}) {
  const x = useMemo(() => {
    const x = [];
    x.push(a);
    return x;
  }, [a])

  const y = useMemo(() => {
    const y = x;
    y.push(b);
    return y;
  }, [x, b])

  return <Child x={x} />;
}

現(xiàn)在問題來了，優(yōu)化前后的代碼邏輯相同么？你可以仔細(xì)觀察下。

答案是 —— 不相同。

優(yōu)化后，在首次render時(shí)，x、y都會指向數(shù)組[a, b]，如下圖：