C++ 名稱空間
前言
對於單執行緒來說,事件迴圈可以說是重中之重了,它為任務分配不同的優先順序,井然有序的排程。讓js解析,使用者互動,頁面渲染等互不衝突,各司其職。
我們書寫的程式碼無時無刻都在和事件迴圈打交道,要想寫出更流暢,我們就必須深入瞭解事件迴圈,下面我們將從規範中翻譯和解讀整個流程。
以下內容來自whatwg文件,均為個人理解,若有不對,煩請指出,我會第一時間修改,避免誤導他人!
正文
為了協呼叫戶操作,js執行,頁面渲染,網路請求等事件,每個宿主中,存在事件迴圈這樣的角色,並且該角色在當前宿主中是唯一的。
簡單解釋一下宿主:宿主是一個ECMAScript執行上下文,一般包含執行上下文棧,執行時執行環境,宿主記錄和一個執行執行緒,除了這個執行執行緒外,其他的專屬於當前宿主。例如,某些瀏覽器在不同的tabs使用同一個執行執行緒。
不僅如此,事件迴圈又存於在各個不同場景,有瀏覽器環境下的,worker環境下的和Worklet環境下的。
Worklet是一個輕量級的web worker,可以讓開發者訪問更底層的渲染工作線,也就是說你可以通過Worklet去幹預瀏覽器的渲染環境。
提到了worklet,那就順便看一個例子(需開啟服務,不要以file協議執行),通過這個例子,可以看到事件迴圈不同階段觸發了什麼鉤子函式:
<!DOCTYPE html><html lang='en'> <head> <meta charset='UTF-8' /> <meta name='viewport' content='width=device-width, initial-scale=1.0' /> <title>Document</title> <style> .fancy { background-image: paint(headerHighlight); display: layout(sample-layout); background-color: green; } </style> </head> <body> <h1 class='fancy'>My Cool Header</h1> <script> console.log('開始'); CSS.paintWorklet.addModule('./paint.js'); CSS.layoutWorklet.addModule('./layout.js'); requestAnimationFrame(() => { console.log('requestAnimationFrame'); }); Promise.resolve().then(() => { console.log('微任務'); }); setTimeout(function () { document.querySelector('.fancy').style.height = '150px'; ('translateZ(0)'); Promise.resolve().then(() => { console.log('新一輪的微任務'); }); requestAnimationFrame(() => { console.log('新一輪的requestAnimationFrame'); }); }, 2000); console.log(2); </script> </body></html>
// paint.jsregisterPaint( 'headerHighlight', class { static get contextOptions() { console.log('contextOptions'); return {alpha: true}; } paint(ctx) { console.log('paint函式'); } });// ==========================分割線// layout.jsregisterLayout( 'sample-layout', class { async intrinsicSizes(children, edges, styleMap) {} async layout(children, edges, constraints, styleMap, breakToken) { console.log('layout階段'); } });
事件迴圈有一個或多個Task佇列,每個Task佇列都是Task的一個集合。其中Task不是指我們的某個函式,而是一個上下文環境,結構如下:
- step:一系列任務將要執行的步驟
- source:任務來源,常用來對相關任務進行分組和系列化
- document:與當前任務相關的document物件,如果是非window環境則為null
- 環境配置物件:在任務期間追蹤記錄任務狀態
這裡的Task佇列不是Task,是一個集合,因為取出一個Task佇列中的Task是選擇一個可執行的Task,而不是出隊操作。
微任務佇列是一個入對出對的佇列。
這裡說明一下,Task佇列為什麼有多個,因為不同的Task佇列有不同的優先順序,進而進行次序排列和呼叫,有沒有感覺react的fiber和這個有點類似?
舉個例子,Task佇列可以是專門負責滑鼠和鍵盤事件的,並且賦予滑鼠鍵盤佇列較高的優先順序,以便及時響應使用者操作。另一個Task佇列負責其他任務源。不過也不要餓死任何一個task,這個後續處理模型中會介紹。
Task封裝了負責以下任務的演算法:
- Events: 由專門的Task在特定的EventTarget(一個具有監聽訂閱模式列表的物件)上分發事件物件
- Parsing: html解析器標記一個或多個位元組,並處理所有生成的結果token
- Callbacks: 由專門的Task觸發回撥函式
- Using a resource: 當該演算法獲取資源的時候,如果該階段是以非阻塞方式發生,那麼一旦部分或者全部資源可用,則由Task進行後續處理
- Reacting to DOM manipulation: 通過dom操作觸發的任務,例如插入一個節點到document
事件迴圈有一個當前執行中的Task,可以為null,如果是null的話,代表著可以接受一個新的Task(新一輪的步驟)。
事件迴圈有微任務佇列,預設為空,其中的任務由微任務排隊演算法建立。
事件迴圈有一個執行微任務檢查點,預設為false,用來防止微任務死迴圈。
- 如果未提供event loop,設定一個隱式event loop。
- 如果未提供document,設定一個隱式document.
- 建立一個Task作為新的微任務
- 設定setp、source、document到新的Task上
- 設定Task的環境配置物件為空集
- 新增到event loop的微任務佇列中
微任務檢查演算法:
- 如果微任務檢查標誌為true,直接return
- 設定微任務檢查標誌為true
- 如果微任務隊裡不為空(也就是說微任務新增的微任務也會在這個迴圈中出現,直到微任務佇列為空):
- 從微任務佇列中找出最老的任務(防餓死)
- 設定當前執行任務為這個最老的任務
- 執行
- 重置當前執行任務為null
- 通知環境配置物件的promise進行reject操作
- 清理indexdb事務(不太明白這一步,如果有讀者瞭解,煩請點撥一下)
- 設定微任務檢查標誌為false
處理模型
event loop會按照下面這些步驟進行排程:
- 找到一個可執行的Task佇列,如果沒有則跳轉到下面的微任務步驟
- 讓最老的Task作為Task佇列中第一個可執行的Task,並將其移除
- 將最老的Task作為event loop的可執行Task
- 記錄任務開始時間點
- 執行Task中的setp對應的步驟(上文中Task結構中的step)
- 設定event loop的可執行任務為null
- 執行微任務檢查演算法
- 設定hasARenderingOpportunity(是否可以渲染的flag)為false
- 記住當前時間點
- 通過下面步驟記錄任務持續時間
- 設定頂層瀏覽器環境為空
- 對於每個最老Task的指令碼執行環境配置物件,設定當前的頂級瀏覽器上下文到其上
- 報告消耗過長的任務,並附帶開始時間,結束時間,頂級瀏覽器上下文和當前Task
- 如果在window環境下,會根據硬體條件決定是否渲染,比如重新整理率,頁面效能,頁面是否在後臺,不過渲染會定期出現,避免頁面卡頓。值得注意的是,正常的重新整理率為60hz,大概是每秒60幀,大約16.7ms每幀,如果當前瀏覽器環境不支援這個重新整理率的話,會自動降為30hz,而不是丟幀。而李蘭其在後臺的時候,聰明的瀏覽器會將這個渲染時機降為每秒4幀甚至更低,事件迴圈也會減少(這就是為什麼我們可以用setInterval來判斷時候能開啟其他app的判斷依據的原因)。如果能渲染的話會設定hasARenderingOpportunity為true。
除此之外,還會在觸發resize、scroll、建立媒體查詢、執行css動畫等,也就是說瀏覽器幾乎大部分使用者操作都發生在事件迴圈中,更具體點是事件迴圈中的ui render部分。之後會進行requestAnimationFrame和IntersectionObserver的觸發,再之後是ui渲染
- 如果下面條件都成立,那麼執行空閒階段演算法,對於開發者來說就是呼叫window.requestIdleCallback方法
- 在window環境下
- event loop中沒有活躍的Task
- 微任務佇列為空
- hasARenderingOpportunity為false
借鑑網上的一張圖來粗略表示下整個流程
小結
上面就是整個事件迴圈的流程,瀏覽器就是按照這個規則一遍遍的執行,而我們要做的就是了解並適應這個規則,讓瀏覽器渲染出效能更高的頁面。
比如:
- 非首屏相關效能打點可以放到idle callback中執行,減少對頁面效能的損耗
- 微任務中遞迴新增微任務會導致頁面卡死,而不是隨著事件迴圈一輪輪的執行
- 更新元素佈局的最好時機是在requestAnimateFrame中
- 儘量避免頻繁獲取元素佈局資訊,因為這會觸發強制layout(哪些屬性會導致強制layout?),影響頁面效能
- 事件迴圈有多個任務佇列,他們互不衝突,但是使用者互動相關的優先順序更高
- resize、scroll等會伴隨事件迴圈中ui渲染觸發,而不是根據我們的滾動觸發,換句話說,這些操作自帶節流
- 等等,歡迎補充
最後感謝大家閱讀,歡迎一起探討!