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