跟著whatwg看一遍事件迴圈
前言
對於單執行緒來說，事件迴圈可以說是重中之重了，它為任務分配不同的優先順序，井然有序的排程。讓js解析，使用者互動，頁面渲染等互不衝突，各司其職。
我們書寫的程式碼無時無刻都在和事件迴圈打交道，要想寫出更流暢，我們就必須深入瞭解事件迴圈，下面我們將從規範中翻譯和解讀整個流程。
以下內容來自whatwg檔案，均為個人理解，若有不對，煩請指出，我會第一時間修改，避免誤導他人！
正文
為了協呼叫戶操作，js執行，頁面渲染，網路請求等事件，每個宿主中，存在事件迴圈這樣的角色，並且該角色在當前宿主中是唯一的。
簡單解釋一下宿主：宿主是一個ECMAScript執行上下文，一般包含執行上下文棧，執行時執行環境，宿主記錄和一個執行執行緒，除了這個執行執行緒外，其他的專屬於當前宿主。例如，某些瀏覽器在不同的tabs使用同一個執行執行緒。
不僅如此，事件迴圈又存於在各個不同場景，有瀏覽器環境下的，worker環境下的和Worklet環境下的。
Worklet是一個輕量級的web worker，可以讓開發者訪問更底層的渲染工作線，也就是說你可以通過Worklet去幹預瀏覽器的渲染環境。
提到了worklet，那就順便看一個例子(需開啟服務，不要以file協議執行)，通過這個例子，可以看到事件迴圈不同階段觸發了什麼鉤子函式：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<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.js
registerPaint(
'headerHighlight',
class {
static get contextOptions() {
console.log('contextOptions');
return {alpha: true};
}
paint(ctx) {
console.log('paint函式');
}
}
);
// ==========================分割線
// layout.js
registerLayout(
'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渲染觸發，而不是根據我們的滾動觸發，換句話說，這些操作自帶節流
- 等等，歡迎補充
最後感謝大家閱讀，歡迎一起探討！