一加Ace2 Pro官宣：普及16G內(nèi)存 引領(lǐng)24G
一加官方今天繼續(xù)為本月發(fā)布的新機一加Ace2 Pro帶來預(yù)熱，公布了內(nèi)存方面的信息。“淘汰 8GB ，12GB 起步，16GB 普及，24GB 引領(lǐng)，還有呢？#一加Ace2Pro#，2023 年 8 月，敬請期待。”同時
雖然之前有跟大家分享過不少卡頓相關(guān)的內(nèi)容，實際上網(wǎng)頁里卡頓的產(chǎn)生基本上都是由于長任務(wù)導(dǎo)致的。當(dāng)然，能阻塞用戶操作的，我們說的便是主線程上的長任務(wù)。
瀏覽器中的長任務(wù)可能是 JavaScript 的編譯、解析 HTML 和 CSS、渲染頁面，或者是我們編寫的 JavaScript 中產(chǎn)生了長任務(wù)導(dǎo)致。
之前在介紹前端性能優(yōu)化--卡頓篇時，提到可以將大任務(wù)進行拆解：
考慮將任務(wù)執(zhí)行耗時控制在 50 ms 左右。每執(zhí)行完一個任務(wù)，如果耗時超過 50 ms，將剩余任務(wù)設(shè)為異步，放到下一次執(zhí)行，給到頁面響應(yīng)用戶操作和更新渲染的時間。
為什么是 50 毫秒呢？
這個數(shù)值并不是隨便寫的，主要來自于 Google 員工開發(fā)的 RAIL 模型。
RAIL 表示 Web 應(yīng)用生命周期的四個不同方面：響應(yīng)（Response）、動畫（Animation）、空閑（Idel）和加載（Load）。由于用戶對每種情境有不同的性能預(yù)期，因此，系統(tǒng)會根據(jù)情境以及關(guān)于用戶如何看待延遲的用戶體驗調(diào)研來確定效果目標(biāo)。
人機交互學(xué)術(shù)研究由來已久，在 Jakob Nielsen’s work on response time limits 中提出三個閾值：
在此基礎(chǔ)上，如今機器性能都有大幅度的提升，因此基于用戶的體驗，RAIL 增加了一項：
由于這篇文章我們討論的是長任務(wù)相關(guān)，因此主要考慮生命周期中的響應(yīng)（Response），目標(biāo)便是要求 100 毫秒內(nèi)獲得可見響應(yīng)。
RAIL 的目標(biāo)是在 100 毫秒內(nèi)完成由用戶輸入發(fā)起的轉(zhuǎn)換，讓用戶感覺互動是瞬時完成的。
目標(biāo)是 100 毫秒，但是頁面運行時除了輸入處理之外，通常還會執(zhí)行其他工作，并且這些工作會占用可用于獲得可接受輸入響應(yīng)的部分時間。
因此，為確保在 100 毫秒內(nèi)獲得可見響應(yīng)，RAIL 的準(zhǔn)則是在 50 毫秒內(nèi)處理用戶輸入事件：
為確保在 100 毫秒內(nèi)獲得可見響應(yīng)，請在 50 毫秒內(nèi)處理用戶輸入事件。這適用于大多數(shù)輸入，例如點擊按鈕、切換表單控件或啟動動畫。這不適用于輕觸拖動或滾動。
除了響應(yīng)之外，RAIL 對其他的生命周期也提出了對應(yīng)的準(zhǔn)則，總體為：
具體每個行為的目標(biāo)和準(zhǔn)則是如何考慮和確定的，大家可以自行學(xué)習(xí)，這里不再贅述。
網(wǎng)頁加載時，長時間任務(wù)可能會占用主線程，使頁面無法響應(yīng)用戶輸入（即使頁面看起來已就緒）。點擊和點按通常不起作用，因為尚未附加事件監(jiān)聽器、點擊處理程序等。
基于前面介紹的 RAIL 模型，我們可以將超過 50 毫秒的任務(wù)稱之為長任務(wù)，即：任何連續(xù)不間斷的且主 UI 線程繁忙 50 毫秒及以上的時間區(qū)間。
實際上，Chrome 瀏覽器中的 Performance 面板也是如此定義的，我們錄制一段 Performance，當(dāng)主線程同步執(zhí)行的任務(wù)超過 50 毫秒時，該任務(wù)塊會被標(biāo)記為紅色。
一般來說，在前端網(wǎng)頁中容易出現(xiàn)的長任務(wù)包括：
(1) 使用 Chrome Devtools
我們可以在 Chrome 開發(fā)者工具中，通過錄制 Performance 的方式，手動查找時長超過 50 毫秒的腳本的“長紅/黃色塊”，然后分析這些任務(wù)塊的執(zhí)行內(nèi)容，來識別出長任務(wù)。
我們可以選擇 Bottom-Up 和 Group by Activity 面板來分析這些長任務(wù)（關(guān)于如何使用 Performance 面板，可以參考分析運行時性能一文）：
比如在上圖中，導(dǎo)致任務(wù)耗時較長的原因是一組成本高昂的 DOM 查詢。
(2) 使用 Long Tasks API
我們還可以使用 Long Tasks API 來確定哪些任務(wù)導(dǎo)致互動延遲：
new PerformanceObserver(function (list) { const perfEntries = list.getEntries(); for (let i = 0; i < perfEntries.length; i++) { // 分析長任務(wù) }}).observe({ entryTypes: ["longtask"] });(3) 識別大型腳本
大型腳本通常是導(dǎo)致耗時較長的任務(wù)的主要原因，我們可以想辦法來識別。
除了使用上述的方法，我們還可以使用PerformanceObserver識別：
new PerformanceObserver((resource) => { const entries = resource.getEntries(); entries.forEach((entry: PerformanceResourceTiming) => { // 獲取 JavaScript 資源 if (entry.initiatorType !== 'script') return; const startTime = new Date().getTime(); window.requestAnimationFrame(() => { // JavaScript 資源加載完成 const endTime = new Date().getTime(); // 如果此時耗時大于 50 ms，則可任務(wù)出現(xiàn)了長任務(wù) const isLongTask = endTime - startTime > 50; }); });}).observe({entryTypes: ['resource']});這種方式我們還可以通過entry.name拿到對應(yīng)的加載資源，針對性地進行處理。
(4) 自定義性能指標(biāo)
除此之外，我們還可以通過在代碼中埋點，自行計算執(zhí)行耗時，從而針對可預(yù)見的場景識別出長任務(wù)：
// 可預(yù)見的大任務(wù)執(zhí)行前打點performance.mark('bigTask:start');await doBigTask();// 執(zhí)行后打點performance.mark('bigTask:end');// 測量該任務(wù)performance.measure('bigTask', 'bigTask:start', 'bigTask:end');再配合PerformanceObserver獲取對應(yīng)的性能數(shù)據(jù)，大于 50 毫秒則可以判斷為長任務(wù)、
發(fā)現(xiàn)長任務(wù)之后，我們就可以進行對應(yīng)的長任務(wù)優(yōu)化。
大型腳本通常是導(dǎo)致耗時較長的任務(wù)的主要原因，尤其是首屏加載時盡量避免加載不必要的代碼。
我們可以考慮拆分這些腳本：
拆分 JavaScript 腳本，使得用戶打開頁面時，只發(fā)送初始路由所需的代碼。這樣可以最大限度地減少需要解析和編譯的腳本量，從而縮短網(wǎng)頁加載時，也有助于提高 First Input Delay (FID) 和 Interaction to Next Paint (INP) 時間。
有很多工具可以幫助我們完成這項工作：
這些熱門的模塊打包器，都支持動態(tài)加載的方式來拆分 JavaScript 腳本。我們甚至可以限制每個構(gòu)建模塊的大小，來防止某個模塊的 JavaScript 腳本過大，具體的使用方式大家可以自行搜索。
主線程一次只能處理一個任務(wù)。如果任務(wù)的延時時間超過某一點（確切來說是 50 毫秒），則會被歸類為耗時較長的任務(wù)。
對于這種過長的執(zhí)行任務(wù)，優(yōu)化方案也十分直接：任務(wù)拆分，直觀來看就是這樣：
一般來說，任務(wù)拆分可以分為兩種：
(1) 串行任務(wù)的拆分
對于串行執(zhí)行的不同任務(wù)，可以將不同任務(wù)的調(diào)用從同步改成異步即可，比如 Optimize long tasks 這篇文章中詳細介紹的：
saveSettings()的函數(shù)，該函數(shù)會調(diào)用五個函數(shù)來完成某些工作：
function saveSettings () { validateForm(); showSpinner(); saveToDatabase(); updateUI(); sendAnalytics();}
對這些串行任務(wù)進行拆分有很多種方式，比如：
具體的代碼可以參考 Optimize long tasks 該文章，理想的優(yōu)化效果為：
(2) 單個超大任務(wù)的拆分
有時候我們的應(yīng)用中需要做大量的運算，比如對上百萬個數(shù)據(jù)做一系列的計算，此時我們可以考慮進行分批拆分。
拆分的時候需要注意幾個事情：
之前在介紹復(fù)雜渲染引擎的時候，有詳細講解使用分批計算的方法進行性能優(yōu)化，具體可以參考《復(fù)雜渲染引擎架構(gòu)與設(shè)計--5.分片計算》一文。
對于大型復(fù)雜的前端應(yīng)用來說，卡頓和長任務(wù)都是家常便飯。
性能優(yōu)化沒有捷徑，有的都是一步步定位，一點點分析，一處處解決。每一個問題都是獨立的問題，但我們還可以識別它們的共性，提供更高效的解決路徑。
本文鏈接：http://www.www897cc.com/showinfo-26-88566-0.html前端性能優(yōu)化：讓你的長任務(wù)保持在50ms 內(nèi)
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號