新穎的 setTimeout() 替代方案 scheduler.yield()
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
在前端開發(fā)中,長時(shí)間運(yùn)行的JavaScript任務(wù)一直是一個(gè)棘手的問題。它們會(huì)導(dǎo)致頁面無響應(yīng),影響用戶體驗(yàn)。傳統(tǒng)上,開發(fā)者使用 長任務(wù)的問題為了說明長任務(wù)的問題,以下是一個(gè)示例,任何字符都有其代碼,但并非所有代碼都有相關(guān)字符。所有非字符代碼都顯示為白色垂直矩形。您可以在下面顯示與一系列代碼相對(duì)應(yīng)的字符的頁面中看到許多代碼: ? 有很多垂直的矩形,想把它們過濾掉,通過遍歷一系列Unicode字符代碼,過濾掉未分配的代碼點(diǎn)。
這段代碼在執(zhí)行過程中會(huì)使頁面凍結(jié)約4279毫秒,而在此期間,頁面一直處于凍結(jié)狀態(tài)。即使點(diǎn)擊后代碼會(huì)首先移除按鈕,但只要代碼還在運(yùn)行,瀏覽器就無法更新屏幕。代碼運(yùn)行結(jié)束后,瀏覽器也無法顯示任何字符,按鈕會(huì)被移除,字符也會(huì)一并顯示, 導(dǎo)致用戶體驗(yàn)不佳。 因此,在長時(shí)間工作時(shí),一定要暫停,讓瀏覽器更新屏幕。可以使用類似的語句暫時(shí)中止或中斷長代碼的執(zhí)行. 使用setTimeout()分割任務(wù)傳統(tǒng)的解決方法是使用
這種方法雖然使頁面保持響應(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í), 在上面的頁面中,兩個(gè)函數(shù)two()同時(shí)運(yùn)行:
當(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()的優(yōu)勢(shì)
示例比較:
結(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è): 在與 結(jié)語
在實(shí)際應(yīng)用中,開發(fā)者可以考慮在處理大量數(shù)據(jù)處理、復(fù)雜計(jì)算或頻繁DOM操作等場(chǎng)景時(shí)使用 該文章在 2024/10/19 12:30:12 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |