在前端開發(fā)中，長(zhǎng)時(shí)間運(yùn)行的JavaScript任務(wù)一直是一個(gè)棘手的問題。它們會(huì)導(dǎo)致頁面無響應(yīng)，影響用戶體驗(yàn)。傳統(tǒng)上，開發(fā)者使用setTimeout()來分割長(zhǎng)任務(wù)，但這種方法存在明顯的缺陷。最近，Chrome 129引入了一種新的、更高效的方法：scheduler.yield()。本文將深入探討這種新技術(shù)，并比較其與傳統(tǒng)方法的優(yōu)劣。

長(zhǎng)任務(wù)的問題

為了說明長(zhǎng)任務(wù)的問題，以下是一個(gè)示例，任何字符都有其代碼，但并非所有代碼都有相關(guān)字符。所有非字符代碼都顯示為白色垂直矩形。您可以在下面顯示與一系列代碼相對(duì)應(yīng)的字符的頁面中看到許多代碼：

圖片

有很多垂直的矩形，想把它們過濾掉，通過遍歷一系列Unicode字符代碼，過濾掉未分配的代碼點(diǎn)。

const MIN = 127734, MAX = 129686;

function insertChar(code, parent) {
    parent.insertAdjacentText('beforeend', String.fromCodePoint(code));
}

function add(i, parent) {
    if (!likeNull(i)) // 比較字符i和0的canvas
        insertChar(i, parent);
}

function one(div) {
    for (let i = MIN; i < MAX; i++)
        add(i, div);
}

function onClick(func) {
    btn.addEventListener('click', async () => {
        btn.remove();
        const start = Date.now();
        await func(div);
        div.insertAdjacentText("afterend", Date.now() - start);
    });
}

onClick(one);

圖片

這段代碼在執(zhí)行過程中會(huì)使頁面凍結(jié)約4279毫秒，而在此期間，頁面一直處于凍結(jié)狀態(tài)。即使點(diǎn)擊后代碼會(huì)首先移除按鈕，但只要代碼還在運(yùn)行，瀏覽器就無法更新屏幕。代碼運(yùn)行結(jié)束后，瀏覽器也無法顯示任何字符，按鈕會(huì)被移除，字符也會(huì)一并顯示， 導(dǎo)致用戶體驗(yàn)不佳。

因此，在長(zhǎng)時(shí)間工作時(shí)，一定要暫停，讓瀏覽器更新屏幕。可以使用類似的語句暫時(shí)中止或中斷長(zhǎng)代碼的執(zhí)行.

使用setTimeout()分割任務(wù)

傳統(tǒng)的解決方法是使用setTimeout()來分割任務(wù)：

function pause() {
    return new Promise(resolve => setTimeout(resolve));
}

async function two(div) {
    for (let i = MIN; i < MAX; i++) {
        await pause();
        add(i, div);
    }
}

onClick(two);

圖片

這種方法雖然使頁面保持響應(yīng)，但執(zhí)行時(shí)間顯著增加到約17568毫秒。

setTimeout()的缺點(diǎn)

1.最小超時(shí)時(shí)間為4毫秒，即使指定為0

即使瀏覽器無事可做，主任務(wù)也會(huì)暫停至少 4 毫秒。即使指定為零，setTimeout()的最小超時(shí)時(shí)間 也是 >4 ms。事實(shí)上，讓我們來計(jì)算一下。在第一頁中，評(píng)估 1952 個(gè)代碼點(diǎn)需要 4279 毫秒，即每個(gè)代碼需要 ~2 毫秒。在第二個(gè)頁面中，評(píng)估 1952 個(gè)代碼點(diǎn)需要 17568 毫秒，即每個(gè)代碼點(diǎn) ~17568/1952=9毫秒。頁面響應(yīng)速度保持不變，但性能下降也令人印象深刻，這主要是由于超時(shí)的持續(xù)時(shí)間盡可能短。

2.任務(wù)繼續(xù)執(zhí)行時(shí)被放置在隊(duì)列末尾，可能導(dǎo)致優(yōu)先級(jí)問題。

當(dāng)任務(wù)暫停時(shí)，setTimeout() 會(huì)將其作為一個(gè)新任務(wù)放置在隊(duì)列的最末端。因此，瀏覽器不僅會(huì)更新屏幕，還會(huì)先執(zhí)行隊(duì)列中的所有任務(wù)，然后再繼續(xù)執(zhí)行暫停的任務(wù)。

圖片

在上面的頁面中，兩個(gè)函數(shù)two()同時(shí)運(yùn)行：

onClick(()=>Promise.race([two(div),two(div2)]));

當(dāng)?shù)谝粋€(gè)two()提交給主線程時(shí)，第二個(gè)two()會(huì)在第一個(gè)two()繼續(xù)執(zhí)行之前被執(zhí)行。執(zhí)行時(shí)間會(huì)稍有增加，從 17 秒增加到 23 秒，但不會(huì)增加兩倍，因?yàn)榇蟛糠诌\(yùn)行時(shí)間都是由最小超時(shí)加起來的。

scheduler.yield()：新的解決方案

scheduler.yield()提供了一種更高效的方法來讓出主線程：

async function three(div) {
    for (let i = MIN; i < MAX; i++) {
        await scheduler.yield();
        add(i, div);
    }
}

onClick(three);

圖片

使用scheduler.yield()，執(zhí)行時(shí)間減少到約5646毫秒，顯著優(yōu)于setTimeout()方法。

scheduler.yield()的優(yōu)勢(shì)

1. 更高的性能：執(zhí)行時(shí)間更接近于未中斷的任務(wù)。
2. 優(yōu)先級(jí)處理：被暫停的任務(wù)被放置在隊(duì)列頭部，而不是末尾。

示例比較：

// 同時(shí)執(zhí)行兩個(gè)three()函數(shù)
onClick(() => Promise.race([three(div), three(div2)]));

// three()與setTimeout()基于的two()比較
onClick(() => Promise.race([three(div), two(div2)]));

結(jié)果與上述基于setTimeout()的index4.html的不同之處僅在于執(zhí)行時(shí)間。10183 毫秒相當(dāng)于兩次 5645 毫秒。兩個(gè)任務(wù)似乎都沒有優(yōu)先級(jí)。

優(yōu)先級(jí)似乎不起作用，因?yàn)閮蓚€(gè)函數(shù)three()都不在隊(duì)列中等待。但看看這個(gè)：

圖片

在與setTimeout()基于的方法比較時(shí)，scheduler.yield()顯示出明顯的優(yōu)先級(jí)優(yōu)勢(shì)。

結(jié)語

scheduler.yield()為JavaScript中的任務(wù)調(diào)度提供了一個(gè)強(qiáng)大的新工具。它不僅性能更優(yōu)，還能更好地處理任務(wù)優(yōu)先級(jí)。對(duì)于需要處理長(zhǎng)時(shí)間運(yùn)行任務(wù)的前端開發(fā)者來說，這是一個(gè)值得關(guān)注和采用的新技術(shù)。

在實(shí)際應(yīng)用中，開發(fā)者可以考慮在處理大量數(shù)據(jù)處理、復(fù)雜計(jì)算或頻繁DOM操作等場(chǎng)景時(shí)使用scheduler.yield()。這將有助于保持頁面的響應(yīng)性，同時(shí)不會(huì)顯著影響任務(wù)的執(zhí)行效率。隨著瀏覽器支持的增加，scheduler.yield()有望成為前端性能優(yōu)化的重要工具。