React Concurrent Mode三連:是什么/為什么/怎么做
最近發(fā)布的React v17.0沒有包含新特性。
究其原因,v17.0主要的工作在于源碼內(nèi)部對Concurrent Mode的支持。所以v17版本也被稱為“墊腳石”版本。
本文會詳細(xì)介紹Concurrent Mode的來龍去脈,以及這套體系從底層架構(gòu)到上層API的實現(xiàn)。
由于跨度比較長,細(xì)節(jié)難免缺失。對文中提到的細(xì)節(jié)的進(jìn)一步補足,歡迎關(guān)注我的工粽號 —— 魔術(shù)師卡頌,給你一份完整的源碼學(xué)習(xí)方案。
是什么?
Concurrent Mode是什么?你可以從官網(wǎng)Concurrent 模式介紹[1]了解其基本概念。
一句話概括:
- Concurrent 模式是一組 React 的新功能,可幫助應(yīng)用保持響應(yīng),并根據(jù)用戶的設(shè)備性能和網(wǎng)速進(jìn)行適當(dāng)?shù)恼{(diào)整。
為了讓應(yīng)用保持響應(yīng),我們需要先了解是什么在制約應(yīng)用保持響應(yīng)?
我們?nèi)粘J褂肁pp,瀏覽網(wǎng)頁時,有兩類場景會制約保持響應(yīng):
- 當(dāng)遇到大計算量的操作或者設(shè)備性能不足使頁面掉幀,導(dǎo)致卡頓。
- 發(fā)送網(wǎng)絡(luò)請求后,由于需要等待數(shù)據(jù)返回才能進(jìn)一步操作導(dǎo)致不能快速響應(yīng)。
這兩類場景可以概括為:
- CPU的瓶頸
- IO的瓶頸
CPU的瓶頸
當(dāng)項目變得龐大、組件數(shù)量繁多時,就容易遇到CPU的瓶頸。
考慮如下Demo,我們向視圖中渲染3000個li:
- function App() {
- const len = 3000;
- return (
- <ul>
- {Array(len).fill(0).map((_, i) => <li>{i}</li>)}
- </ul>
- );
- }
- const rootEl = document.querySelector("#root");
- ReactDOM.render(<App/>, rootEl);
主流瀏覽器刷新頻率為60Hz,即每(1000ms / 60Hz)16.6ms瀏覽器刷新一次。
我們知道,JS可以操作DOM,GUI渲染線程與JS線程是互斥的。所以JS腳本執(zhí)行和瀏覽器布局、繪制不能同時執(zhí)行。
在每16.6ms時間內(nèi),需要完成如下工作:
- JS腳本執(zhí)行 ----- 樣式布局 ----- 樣式繪制
當(dāng)JS執(zhí)行時間過長,超出了16.6ms,這次刷新就沒有時間執(zhí)行樣式布局和樣式繪制了。
在Demo中,由于組件數(shù)量繁多(3000個),JS腳本執(zhí)行時間過長,頁面掉幀,造成卡頓。
可以從打印的執(zhí)行堆棧圖看到,JS執(zhí)行時間為73.65ms,遠(yuǎn)遠(yuǎn)多于一幀的時間。
如何解決這個問題呢?
答案是:在瀏覽器每一幀的時間中,預(yù)留一些時間給JS線程,React利用這部分時間更新組件(可以看到,在源碼[2]中,預(yù)留的初始時間是5ms)。
當(dāng)預(yù)留的時間不夠用時,React將線程控制權(quán)交還給瀏覽器使其有時間渲染UI,React則等待下一幀時間到來繼續(xù)被中斷的工作。
- 這種將長任務(wù)分拆到每一幀中,像螞蟻搬家一樣一次執(zhí)行一小段任務(wù)的操作,被稱為時間切片(time slice)
所以,解決CPU瓶頸的關(guān)鍵是實現(xiàn)時間切片,而時間切片的關(guān)鍵是:將同步的更新變?yōu)榭芍袛嗟漠惒礁隆?/p>
IO的瓶頸
網(wǎng)絡(luò)延遲是前端開發(fā)者無法解決的。如何在網(wǎng)絡(luò)延遲客觀存在的情況下,減少用戶對網(wǎng)絡(luò)延遲的感知?
React給出的答案是將人機交互研究的結(jié)果整合到真實的 UI 中[3]。
這里我們以業(yè)界人機交互最頂尖的蘋果舉例,在IOS系統(tǒng)中:
點擊“設(shè)置”面板中的“通用”,進(jìn)入“通用”界面:
作為對比,再點擊“設(shè)置”面板中的“Siri與搜索”,進(jìn)入“Siri與搜索”界面:
你能感受到兩者體驗上的區(qū)別么?
事實上,點擊“通用”后的交互是同步的,直接顯示后續(xù)界面。
而點擊“Siri與搜索”后的交互是異步的,需要等待請求返回后再顯示后續(xù)界面。
但從用戶感知來看,這兩者的區(qū)別微乎其微。
這里的竅門在于:點擊“Siri與搜索”后,先在當(dāng)前頁面停留了一小段時間,這一小段時間被用來請求數(shù)據(jù)。
當(dāng)“這一小段時間”足夠短時,用戶是無感知的。如果請求時間超過一個范圍,再顯示loading的效果。
試想如果我們一點擊“Siri與搜索”就顯示loading效果,即使數(shù)據(jù)請求時間很短,loading效果一閃而過。用戶也是可以感知到的。
為此,React實現(xiàn)了Suspense[4]、useDeferredValue[5]。
在源碼內(nèi)部,為了支持這些特性,同樣需要將同步的更新變?yōu)榭芍袛嗟漠惒礁隆?/p>
Concurrent Mode自底向上
底層基礎(chǔ)決定了上層API的實現(xiàn),接下來讓我們了解下,Concurrent Mode自底向上都包含哪些組成部分,才能實現(xiàn)上文提到的功能。
底層架構(gòu) —— Fiber架構(gòu)
從上文我們了解到,為了解決CPU、IO瓶頸,最關(guān)鍵的一點是:實現(xiàn)異步可中斷的更新。
基于這個前提,React花費2年時間重構(gòu)完成了Fiber架構(gòu)。
Fiber機構(gòu)的意義在于,他將單個組件作為工作單元,使以組件為粒度的“異步可中斷的更新”成為可能。
架構(gòu)的驅(qū)動力 —— Scheduler
如果我們同步運行Fiber架構(gòu)(通過ReactDOM.render),則Fiber架構(gòu)與重構(gòu)前并無區(qū)別。
但是當(dāng)我們配合時間切片,就能根據(jù)宿主環(huán)境性能,為每個工作單元分配一個可運行時間,實現(xiàn)“異步可中斷的更新”。
于是,scheduler[6](調(diào)度器)產(chǎn)生了。
Scheduler能保證我們的長任務(wù)被拆分到每一幀不同的task中。
當(dāng)我們?yōu)樯衔闹v到的渲染3000個li的Demo開啟Concurrent Mode:
- // 通過使用ReactDOM.unstable_createRoot開啟Concurrent Mode
- // ReactDOM.render(<App/>, rootEl);
- ReactDOM.unstable_createRoot(rootEl).render(<App/>);
可以看到,每段JS腳本執(zhí)行時間大體在5ms左右。
這樣瀏覽器就有剩余時間執(zhí)行樣式布局和樣式繪制,減少掉幀的可能性。
Fiber架構(gòu)配合Scheduler實現(xiàn)了Concurrent Mode的底層剛需 —— “異步可中斷的更新”。
架構(gòu)運行策略 —— lane模型
到目前為止,通過Scheduler,React可以控制更新在Fiber架構(gòu)中運行/中斷/繼續(xù)運行。
基于當(dāng)前的架構(gòu),當(dāng)一次更新在運行過程中被中斷,過段時間再繼續(xù)運行,這就是“異步可中斷的更新”。
當(dāng)一次更新在運行過程中被中斷,轉(zhuǎn)而重新開始一次新的更新,我們可以說:后一次更新打斷了前一次更新。
這就是優(yōu)先級的概念:后一次更新的優(yōu)先級更高,他打斷了正在進(jìn)行的前一次更新。
多個優(yōu)先級之間如何互相打斷?優(yōu)先級能否升降?本次更新應(yīng)該賦予什么優(yōu)先級?
這就需要一個模型控制不同優(yōu)先級之間的關(guān)系與行為,于是lane模型誕生了。
- lane模型通過將不同優(yōu)先級賦值給一個位,通過31位的位運算來操作優(yōu)先級
如下是不同優(yōu)先級的定義:
- export const NoLanes: Lanes = /* */ 0b0000000000000000000000000000000;
- export const NoLane: Lane = /* */ 0b0000000000000000000000000000000;
- export const SyncLane: Lane = /* */ 0b0000000000000000000000000000001;
- export const SyncBatchedLane: Lane = /* */ 0b0000000000000000000000000000010;
- export const InputDiscreteHydrationLane: Lane = /* */ 0b0000000000000000000000000000100;
- const InputDiscreteLanes: Lanes = /* */ 0b0000000000000000000000000011000;
- // 省略...
上層實現(xiàn)
現(xiàn)在,我們可以說:
- 從源碼層面講,Concurrent Mode是一套可控的“多優(yōu)先級更新架構(gòu)”。
那么基于該架構(gòu)之上可以實現(xiàn)哪些有意思的功能?我們舉幾個例子:
batchedUpdates
如果我們在一次事件回調(diào)中觸發(fā)多次更新,他們會被合并為一次更新進(jìn)行處理。
如下代碼執(zhí)行只會觸發(fā)一次更新:
- onClick() {
- this.setState({stateA: 1});
- this.setState({stateB: false});
- this.setState({stateA: 2});
- }
這種合并多個更新的優(yōu)化方式被稱為batchedUpdates。
batchedUpdates在很早的版本就存在了,不過之前的實現(xiàn)局限很多(脫離當(dāng)前上下文環(huán)境的更新不會被合并)。
在Concurrent Mode中,是以優(yōu)先級為依據(jù)對更新進(jìn)行合并的,使用范圍更廣。
Suspense
Suspense[7]可以在組件請求數(shù)據(jù)時展示一個pending狀態(tài)。請求成功后渲染數(shù)據(jù)。
本質(zhì)上講Suspense內(nèi)的組件子樹比組件樹的其他部分擁有更低的優(yōu)先級。
useDeferredValue
useDeferredValue[8]返回一個延遲響應(yīng)的值,該值可能“延后”的最長時間為timeoutMs。
例子:
- const deferredValue = useDeferredValue(value, { timeoutMs: 2000 });
在useDeferredValue內(nèi)部會調(diào)用useState并觸發(fā)一次更新。
這次更新的優(yōu)先級很低,所以當(dāng)前如果有正在進(jìn)行中的更新,不會受useDeferredValue產(chǎn)生的更新影響。所以useDeferredValue能夠返回延遲的值。
當(dāng)超過timeoutMs后useDeferredValue產(chǎn)生的更新還沒進(jìn)行(由于優(yōu)先級太低一直被打斷),則會再觸發(fā)一次高優(yōu)先級更新。
總結(jié)
除了以上介紹的實現(xiàn),可以預(yù)見,當(dāng)v17完美支持Concurrent Mode后,v18會迎來一大波基于Concurrent Mode的庫。