K60至尊版狂暴引擎2.0加持：超177萬跑分斬獲性能第一
Redmi的后性能時代戰(zhàn)略發(fā)布會今天下午如期舉辦，在本次發(fā)布會上，Redmi公布了多項關于和聯(lián)發(fā)科的深度合作，以及新機K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
React Compiler 終于開源了。
自從從它第一次在 React Conf 2021 亮相。到現(xiàn)在 React Conf 2024 正式開源，我已經苦等了三年之久。盼星星盼月亮，終于把他給盼來了。
i
以前叫 React Forget，現(xiàn)改名為 React Compiler。
要了解 React Compiler，這還需要從 React 的更新機制說起。React 項目中的任何一個組件發(fā)生 state 狀態(tài)的變更，React 更新機制都會從最頂層的根節(jié)點開始往下遞歸對比，通過雙緩存機制判斷出哪些節(jié)點發(fā)生了變化，然后更新節(jié)點。這樣的更新機制成本并不小，因為在判斷過程中，如果 React 發(fā)現(xiàn) props、state、context 任意一個不同，那么就認為該節(jié)點被更新了。因此，冗余的 re-render 在這個過程中會大量發(fā)生。
?
對比的成本非常小，但是 re-render 的成本偏高，當我們在短時間之內快速更改 state 時，程序大概率會存在性能問題。因此在以往的開發(fā)方式中，掌握性能優(yōu)化的手段是高級 React 開發(fā)者的必備能力。
一個組件節(jié)點在 React 中很難被判斷為沒有發(fā)生過更新。因為 props 的比較總是不同的。它的比較方式如下。
{} === {} // false因此，高級 React 開發(fā)者需要非常了解 React 的默認優(yōu)化機制，讓 props 的比較不發(fā)生，因為一旦發(fā)生，那么結果必定是 false。
i
事實上，對 React 默認優(yōu)化機制了解的開發(fā)者非常少，我們在開發(fā)過程中也不會為了優(yōu)化這個性能去重新調整組件的分布。更多的還是使用 memo 與 useMemo/useCallback 暴力緩存節(jié)點。
在這樣的背景之下，冗余的 re-render 在大量的項目中發(fā)生。這也是為什么 React 總是唄吐槽性能不好的主要原因。當然，大多數(shù)項目并沒有頻繁更新 state 的需求，因此這一點性能問題表現(xiàn)得并不是很明顯。
如果我們要解決冗余 re-render 的問題，需要對 React 默認優(yōu)化技能有非常深刻的理解，需要對 memo、useCallback、useMemo 有準確的理解。但是普通的 React 開發(fā)者很難理解他們，有的開發(fā)者雖然在項目中大量使用了，但是未必就達到了理想的效果。React Compiler 則是為了解決這個問題，它可以自動幫助我們記憶已經存在、并且沒有發(fā)生更新的組件，從而解決組件冗余 re-render 的問題。
從使用結果的體驗來看，React Compiler 被集成在代碼自動編譯中，因此只要我們在項目中引入成功，就不再需要關注它的存在。我們的開發(fā)方式不會發(fā)生任何改變。它不會更改 React 現(xiàn)有的開發(fā)范式和更新方式，侵入性非常弱。
并非所有的組件都能被優(yōu)化。因此早在 React 18 的版本中，React 官方團隊就提前發(fā)布了嚴格模式。在頂層根節(jié)點中，套一層 StrictMode 即可。
<StrictMode> <BrowserRouter> <App /> </BrowserRouter></StrictMode>遵循嚴格模式的規(guī)范，我們的組件更容易符合 React Compiler 的優(yōu)化規(guī)則。
我們可以使用如下方式首先檢測代碼庫是否兼容。在項目根目錄下執(zhí)行如下指令。
npx react-compiler-healthcheck?
該腳本主要用于檢測。
1、項目中有多少組件可以成功優(yōu)化：越多越好。
2、是否使用嚴格模式，使用了優(yōu)化成功率更高。
3、是否使用了與 Compiler 不兼容的三方庫。
例如，我的其中一個項目，檢測結果如下：
很棒。
這里需要注意的是，引入了 Compiler 插件之后，它會自動工作，我們完全不用關注它的存在。因此，如果程序不出問題，對于開發(fā)者來說，編譯工作是無感的。所以開發(fā)體驗非常棒。
!
不過有一些美中不足的是，當我嘗試驗證其他已經寫好的組件被編譯之后是否存在問題時，發(fā)現(xiàn)有一個組件的運行邏輯發(fā)生了變化。目前我還沒有深究具體是什么原因導致的，不過通過對比，這個組件的獨特之處在與，我在該組件中使用了 useDeferredValue 來處理異步請求。
另外，Compiler 也不能阻止 context 組件的 re-render。例如我在一個組件中使用了 use(context) ，哪怕我并沒有使用具體的值。如下所示。
import {use} from 'react'import {Context} from './context'export default function Card() { const value = use(Context) console.log('xxxxx context') return ( <> <div className='_06_card'> <div className="title">Canary</div> <p>The test page</p> </div> </> )}理想情況是這種情況可以不用發(fā)生 re-render。因此總體來說，Compiler 目前確實還不能完全信任。也有可能我還沒掌握正確的姿勢，還需要對他有更進一步的了解才可以。
不過值得高興的是，新項目可以放心使用 Compiler，因為運行結果我們都能實時感知、調試、調整，能最大程度的避免問題的出現(xiàn)。
React Compiler 編譯之后的代碼并非是在合適的時機使用 useMemo/memo 等 API 來緩存組件。而是使用了一個名為 useMemoCache 的 hook 來緩存代碼片段。
Compiler 會分析所有可能存在的返回結果，并把每個返回結果都存儲在 useMemoCache 中。如上圖所示，他打破了原有的鏈表存儲結果，而選擇把緩存結構存儲在數(shù)組上。因此在執(zhí)行效率上，Compiler 之后的代碼會高不少。每一個渲染結果都會被存儲在 useMemoCache 的某一項中，如果判斷之后發(fā)現(xiàn)該結果可以復用，則直接通過讀取序列的方式使用即可。如圖所示。
因此，編譯之后的代碼看上去會更加的繁雜。但是執(zhí)行卻會更加高效。
初次感受下來，雖然感覺還不錯。但是依然會有一種自己寫的代碼被魔改的不適感。特別是遇到問題的時候，還不知道到底編譯器干了什么事情讓最終運行結果與預想的完全不同。
i
這也是我不太喜歡使用 Solid 與 Svelte 的根本原因。不過 React 好在可以不用...
但是從執(zhí)行性能上確實會有大的提高，這一點對于初學者可能會比較友好。
目前，由于接觸時間太短，我對于 React Compiler 的使用體驗還停留在比較淺的層面。因此能聊的東西并不多，在后續(xù)我有了更進一步更深刻的體會之后，再來跟大家分享體驗結果。
本文鏈接：http://m.www897cc.com/showinfo-26-94294-0.html苦等三年，React Compiler 終于能用了。使用體驗：很爽，但仍有瑕疵
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號