1 回答

TA貢獻(xiàn)1828條經(jīng)驗(yàn) 獲得超6個(gè)贊
為什么這段代碼在執(zhí)行微任務(wù)后不觸發(fā)渲染?
確實(shí)如此,否則您將看不到正在更新的文本...
也許您無法從您的開發(fā)工具中分辨出來?
這可能是因?yàn)槭髽?biāo)事件現(xiàn)在通常被限制為屏幕刷新率,這意味著當(dāng)調(diào)度鼠標(biāo)事件的任務(wù)將運(yùn)行時(shí),您已經(jīng)處于繪畫框架中,這可能是出于其他原因(因?yàn)槲抑R,mousemove事件以這種方式受到限制,而不是單擊...)。
因此,您的Promise 回調(diào)將同步執(zhí)行(只有第六步“將 currentTask 設(shè)置為 null”),在更新渲染步驟開始之前,所有開發(fā)工具都會(huì)看到一個(gè)正常的繪畫框架,就像它在期待。
所以也許,開發(fā)工具在這里不會(huì)顯示任何特別的東西,但是鑒于您的主張的廣泛性,很難確定一個(gè)特定的原因,這只是我的一個(gè)理論。
您可以嘗試通過requestAnimationFrame
從此類事件內(nèi)部調(diào)用來驗(yàn)證該理論,并檢查它是否確實(shí)在同一事件循環(huán)迭代中執(zhí)行:
對我來說,它在 Chrome 中經(jīng)常發(fā)生,在 Firefox 中只是偶爾出現(xiàn)一次,但同時(shí)我知道Chrome 的 rAF 被破壞了......所以這個(gè)理論非常薄弱。
為什么 postmessage 在 timer 之前執(zhí)行?
這將取決于用戶代理(瀏覽器)以及何時(shí)執(zhí)行此代碼以使該語句成立,當(dāng)然也取決于它這樣做的原因。
在 Chrome中,他們?yōu)閭鬟f給的超時(shí)值設(shè)置了至少 1ms setTimeout
:
base::TimeDelta interval_milliseconds = std::max(base::TimeDelta::FromMilliseconds(1), interval);
消息任務(wù)沒有超時(shí),因此將立即排隊(duì)。因此,如果沒有其他任務(wù)要處理,它將是下一個(gè)執(zhí)行的任務(wù),早在 1ms 超時(shí)解決之前。
在 Firefox中,他們將調(diào)度的任務(wù)setTimeout
視為低優(yōu)先級,當(dāng)從頁面加載開始調(diào)度時(shí)(這意味著在 Firefox 中setTimeout
,如果兩者都在頁面加載之后調(diào)度,則消息任務(wù)實(shí)際上會(huì)在一個(gè)之后觸發(fā):
)。
因此,在這種頁面加載的特殊情況下,他們將消息任務(wù)視為比超時(shí)任務(wù)更重要,并且任務(wù)執(zhí)行者必須選擇下一步執(zhí)行哪個(gè)任務(wù)(作為事件第一步的一部分循環(huán)處理模型),它將在超時(shí)后選擇消息。
但這些都是實(shí)現(xiàn)的怪癖,規(guī)范中的任何內(nèi)容都沒有正式化這種行為。
添加回答
舉報(bào)