postTask：React的殺手锏被瀏覽器原生實(shí)現(xiàn)了？

點(diǎn)擊獲取招聘信息：螞蟻體驗(yàn)技術(shù)部招前端

React這幾年一直在完善的「并發(fā)模式」主要由以下兩部分組成：

• 基于fiber實(shí)現(xiàn)的可中斷更新的架構(gòu)

• 基于調(diào)度器的優(yōu)先級(jí)調(diào)度

可以說(shuō)，從16年開(kāi)始重構(gòu)fiber架構(gòu)到今年底（或明年初）React18發(fā)布正式版，這期間React團(tuán)隊(duì)大部分工作都是圍繞這兩點(diǎn)展開(kāi)的。

如果現(xiàn)在告訴你，React嘔心瀝血多年實(shí)現(xiàn)的「優(yōu)先級(jí)調(diào)度」，瀏覽器原生就支持，會(huì)不會(huì)很驚訝？

文章參考Building a Faster Web Experience with the postTask Scheduler^[1]。

什么是優(yōu)先級(jí)調(diào)度

假設(shè)，我們有個(gè)「記錄日志」的腳本需要在頁(yè)面初始化后執(zhí)行：

initCriticalTracking();

調(diào)用?；鹁鎴D如下：

可以看到，這是個(gè)執(zhí)行了249.08ms的長(zhǎng)任務(wù)，在執(zhí)行期間瀏覽器會(huì)掉幀（表現(xiàn)為：瀏覽器卡頓）。

現(xiàn)在，我們將其包裹在「優(yōu)先級(jí)調(diào)度函數(shù)scheduler.postTask」的回調(diào)函數(shù)中：

scheduler.postTask(() => initCriticalTracking());

長(zhǎng)任務(wù)被分解為多個(gè)短任務(wù)：

在每個(gè)任務(wù)之間瀏覽器有機(jī)會(huì)重排、重繪，減少了掉幀的可能性。

這種「根據(jù)任務(wù)優(yōu)先級(jí)將任務(wù)拆解，分配執(zhí)行時(shí)間的技術(shù)」，就是「優(yōu)先級(jí)調(diào)度」。

scheduler.postTask^[2]是Chrome實(shí)現(xiàn)的「優(yōu)先級(jí)調(diào)度API」。

scheduler.postTask屬于試驗(yàn)功能，需要在 chrome://flags 中打開(kāi) #enable-experimental-web-platform-features

之前是如何實(shí)現(xiàn)優(yōu)先級(jí)調(diào)度的

在scheduler.postTask出現(xiàn)之前，通常使用瀏覽器提供的「會(huì)在不同階段調(diào)用的API」模擬「優(yōu)先級(jí)調(diào)度」，比如：

• requestAnimationFrame（簡(jiǎn)稱(chēng)rAF）一般用來(lái)處理動(dòng)畫(huà)，會(huì)在瀏覽器渲染前觸發(fā)

• requestIdleCallback（簡(jiǎn)稱(chēng)rIC）在每一幀沒(méi)有其他任務(wù)的空閑時(shí)間調(diào)用

• setTimeout、postMessage、MessageChannel在渲染之間觸發(fā)

React使用MessageChannel實(shí)現(xiàn)優(yōu)先級(jí)調(diào)度，setTimeout作為降級(jí)方案。

但是，這些API畢竟都有本職工作。用他們實(shí)現(xiàn)的「優(yōu)先級(jí)調(diào)度」比較粗糙。

基于此原因，postTask Scheduler誕生了。

postTask Scheduler的使用

scheduler.postTask有3種可選優(yōu)先級(jí)：

使用方式很簡(jiǎn)單，通過(guò)以下方式注冊(cè)的回調(diào)函數(shù)會(huì)以「默認(rèn)優(yōu)先級(jí)」調(diào)度：

// 默認(rèn)優(yōu)先級(jí)
scheduler.postTask(() => console.log('Hello, postTask'));

你也可以指定優(yōu)先級(jí)與執(zhí)行延遲：

// 調(diào)用后延遲1秒執(zhí)行，優(yōu)先級(jí)最低
scheduler.postTask(() => console.log('Hello, postTask'), {
   delay: 1000,
   priority: 'background',
});

postTask建立在AbortSignal API^[3]上，所以我們可以取消尚在排隊(duì)還未執(zhí)行的回調(diào)函數(shù)。

通過(guò)使用TaskController API控制：

const controller = new TaskController('background');
window.addEventListener('beforeunload', () => controller.abort());
 
scheduler.postTask(() => console.log('Hello, postTask'), {
   signal: controller.signal,
});

同時(shí)，實(shí)驗(yàn)性的schedule.wait方法可以讓我們輕松的等待某一時(shí)機(jī)后再執(zhí)行任務(wù)。

比如，我們可以在頁(yè)面加載完成后異步加載xxx.js：

async function loadxxx() {
  // 等待事件被派發(fā)
  await scheduler.wait('myPageHasLoaded');
  return import('xxx.js');
}
 
// 頁(yè)面加載后派發(fā)事件
window.dispatchEvent(new CustomEvent('myPageHasLoaded'));

以上代碼被簡(jiǎn)化為postTask的event配置項(xiàng)：

scheduler.postTask(() => import('xxx.js'), {
   event: 'myPageHasLoaded'
})

總結(jié)

「優(yōu)先級(jí)調(diào)度」可以應(yīng)用在很多領(lǐng)域，比如：

• 資源提前、延后請(qǐng)求

• 第三方資源延遲加載

......

可以預(yù)見(jiàn)，未來(lái)這勢(shì)必會(huì)增加前端編程復(fù)雜度。

就像曾經(jīng)，當(dāng)web應(yīng)用復(fù)雜到一定程度時(shí)，出現(xiàn)了前端框架，開(kāi)發(fā)者不用直接操作DOM。

未來(lái)，當(dāng)「優(yōu)先級(jí)調(diào)度」復(fù)雜到一定程度時(shí)，一定也會(huì)出現(xiàn)集成解決方案，讓開(kāi)發(fā)者不用直接操作優(yōu)先級(jí)。

慢著，這不就是React現(xiàn)在在做的事么？

參考資料