圖解瀏覽器的基本工作原理
前言
可能每一個前端工程師都想要理解瀏覽器的工作原理。
我們希望知道從在瀏覽器位址列中輸入 url 到頁面展現的短短几秒內瀏覽器究竟做了什麼；
我們希望瞭解平時常常聽說的各種程式碼優化方案是究竟為什麼能起到優化的作用；
我們希望更細化的瞭解瀏覽器的渲染流程。
瀏覽器的多程序架構
一個好的程式常常被劃分為幾個相互獨立又彼此配合的模組，瀏覽器也是如此，以 Chrome 為例，它由多個程序組成，每個程序都有自己核心的職責，它們相互配合完成瀏覽器的整體功能，每個程序中又包含多個執行緒，一個程序內的多個執行緒也會協同工作，配合完成所在程序的職責。
對一些前端開發同學來說，程序和執行緒的概念可能會有些模糊，為了更好的理解瀏覽器的多程序架構，這裡我們簡單討論一下程序和執行緒。
程序（process）和執行緒（thread）
程序就像是一個有邊界的生產廠間，而執行緒就像是廠間內的一個個員工，可以自己做自己的事情，也可以相互配合做同一件事情。
當我們啟動一個應用，計算機會建立一個程序，作業系統會為程序分配一部分記憶體，應用的所有狀態都會儲存在這塊記憶體中，應用也許還會建立多個執行緒來輔助工作，這些執行緒可以共享這部分記憶體中的資料。如果應用關閉，程序會被終結，作業系統會釋放相關記憶體。更生動的示意圖如下：
一個程序還可以要求作業系統生成另一個程序來執行不同的任務，系統會為新的程序分配獨立的記憶體，兩個程序之間可以使用 IPC （Inter Process Communication）進行通訊。很多應用都會採用這樣的設計，如果一個工作程序反應遲鈍，重啟這個程序不會影響應用其它程序的工作。
瀏覽器的架構
有了上面的知識做鋪墊，我們可以更合理的討論瀏覽器的架構了，其實如果要開發一個瀏覽器，它可以是單程序多執行緒的應用，也可以是使用 IPC 通訊的多程序應用。
不同瀏覽器的架構模型不同瀏覽器採用了不同的架構模式，這裡並不存在標準，本文以 Chrome 為例進行說明 ：
Chrome 採用多程序架構，其頂層存在一個 Browser process 用以協調瀏覽器的其它程序。
Chrome 的不同程序具體說來，Chrome 的主要程序及其職責如下：
- Browser Process：
- 負責包括位址列，書籤欄，前進後退按鈕等部分的工作；
- 負責處理瀏覽器的一些不可見的底層操作，比如網路請求和檔案訪問；
- Renderer Process：
- 負責一個 tab 內關於網頁呈現的所有事情
- Plugin Process：
- 負責控制一個網頁用到的所有外掛，如 flash
- GPU Process
- 負責處理 GPU 相關的任務
不同程序負責的瀏覽器區域示意圖
Chrome 還為我們提供了「工作管理員」，供我們方便的檢視當前瀏覽器中執行的所有程序及每個程序佔用的系統資源，右鍵單擊還可以檢視更多類別資訊。
通過「頁面右上角的三個點點點 --- 更多工具 --- 工作管理員」即可開啟相關面板，
Chrome 工作管理員面板
Chrome 多程序架構的優缺點
優點
- 某一渲染程序出問題不會影響其他程序
- 更為安全，在系統層面上限定了不同程序的許可權
缺點
由於不同程序間的記憶體不共享，不同程序的記憶體常常需要包含相同的內容。
為了節省記憶體，Chrome 限制了最多的程序數，最大程序數量由裝置的記憶體和 CPU 能力決定，當達到這一限制時，新開啟的 Tab 會共用之前同一個站點的渲染程序。
Chrome 把瀏覽器不同程式的功能看做服務，這些服務可以方便的分割為不同的程序或者合併為一個程序。以 Broswer Process 為例，如果 Chrome 執行在強大的硬體上，它會分割不同的服務到不同的程序，這樣 Chrome 整體的執行會更加穩定，但是如果 Chrome 執行在資源貧瘠的裝置上，這些服務又會合併到同一個程序中執行，這樣可以節省記憶體，示意圖如下。測試了一下在 Chrome 中開啟不斷開啟知乎首頁，在 Mac i5 8g 上可以啟動四十多個渲染程序，之後新開啟 tab 會合併到已有的渲染程序中。
iframe 的渲染 -- Site Isolation
在上面的程序圖中我們還可以看到一些程序下還存在著 Subframe，這就是 Site Isolation 機制作用的結果。
Site Isolation 機制從 Chrome 67 開始預設啟用。這種機制允許在同一個 Tab 下的跨站 iframe 使用單獨的程序來渲染，這樣會更為安全。
iframe 會採用不同的渲染程序
Site Isolation 被大家看做里程碑式的功能， 其成功實現是多年工程努力的結果。Site Isolation 不是簡單的疊加多個程序。這種機制在底層改變了 iframe 之間通訊的方法，Chrome 的其它功能都需要做對應的調整，比如說 devtools 需要相應的支援，甚至 Ctrl + F 也需要支援。關於 Site Isolation 的更多內容可參考下述連結https://developers.google.com/web/updates/2018/07/site-isolation
介紹完了瀏覽器的基本架構模式，接下來我們看看一個常見的導航過程對瀏覽器來說究竟發生了什麼。
導航過程發生了什麼
也許大多數人使用 Chrome 最多的場景就是在位址列輸入關鍵字進行搜尋或者輸入地址導航到某個網站，我們來看看瀏覽器是怎麼看待這個過程的。
我們知道瀏覽器 Tab 外的工作主要由 Browser Process 掌控，Browser Process 又對這些工作進一步劃分，使用不同執行緒進行處理：
- UI thread ： 控制瀏覽器上的按鈕及輸入框；
- network thread: 處理網路請求，從網上獲取資料；
- storage thread: 控制檔案等的訪問；
回到我們的問題，當我們在瀏覽器位址列中輸入文字，並點選回車獲得頁面內容的過程在瀏覽器看來可以分為以下幾步：
- 處理輸入
UI thread 需要判斷使用者輸入的是 URL 還是 query；
2. 開始導航
當用戶點選回車鍵，UI thread 通知 network thread 獲取網頁內容，並控制 tab 上的 spinner 展現，表示正在載入中。
network thread 會執行 DNS 查詢，隨後為請求建立 TLS 連線
UI thread 通知 Network thread 載入相關資訊如果 network thread 接收到了重定向請求頭如 301，network thread 會通知 UI thread 伺服器要求重定向，之後，另外一個 URL 請求會被觸發。
3. 讀取響應
當請求響應返回的時候，network thread 會依據Content-Type及 MIME Type sniffing 判斷響應內容的格式
判斷響應內容的格式如果響應內容的格式是 HTML ，下一步將會把這些資料傳遞給 renderer process，如果是 zip 檔案或者其它檔案，會把相關資料傳輸給下載管理器。
Safe Browsing檢查也會在此時觸發，如果域名或者請求內容匹配到已知的惡意站點，network thread 會展示一個警告頁。此外CORB檢測也會觸發確保敏感資料不會被傳遞給渲染程序。
4. 查詢渲染程序
當上述所有檢查完成，network thread 確信瀏覽器可以導航到請求網頁，network thread 會通知 UI thread 資料已經準備好，UI thread 會查詢到一個 renderer process 進行網頁的渲染。
收到 Network thread 返回的資料後，UI thread 查詢相關的渲染程序由於網路請求獲取響應需要時間，這裡其實還存在著一個加速方案。當 UI thread 傳送 URL 請求給 network thread 時，瀏覽器其實已經知道了將要導航到那個站點。UI thread 會並行的預先查詢和啟動一個渲染程序，如果一切正常，當 network thread 接收到資料時，渲染程序已經準備就緒了，但是如果遇到重定向，準備好的渲染程序也許就不可用了，這時候就需要重啟一個新的渲染程序。
5. 確認導航
進過了上述過程，資料以及渲染程序都可用了， Browser Process 會給 renderer process 傳送 IPC 訊息來確認導航，一旦 Browser Process 收到 renderer process 的渲染確認訊息，導航過程結束，頁面載入過程開始。
此時，位址列會更新，展示出新頁面的網頁資訊。history tab 會更新，可通過返回鍵返回導航來的頁面，為了讓關閉 tab 或者視窗後便於恢復，這些資訊會存放在硬碟中。
Browser Process 和 Renderer Process 通過 IPC 通訊，請求 Renderer Process 渲染頁面6. 額外的步驟
一旦導航被確認，renderer process 會使用相關的資源渲染頁面，下文中我們將重點介紹渲染流程。當 renderer process 渲染結束（渲染結束意味著該頁面內的所有的頁面，包括所有 iframe 都觸發了 onload 時），會發送 IPC 訊號到 Browser process， UI thread 會停止展示 tab 中的 spinner。
Renderer Process 傳送 IPC 訊息通知 browser process 頁面已經載入完成當然上面的流程只是網頁首幀渲染完成，在此之後，客戶端依舊可下載額外的資源渲染出新的檢視。
在這裡我們可以明確一點，所有的 JS 程式碼其實都由 renderer Process 控制的，所以在你瀏覽網頁內容的過程大部分時候不會涉及到其它的程序。不過也許你也曾經監聽過beforeunload事件，這個事件再次涉及到 Browser Process 和 renderer Process 的互動，噹噹前頁面關閉時（關閉 Tab ，重新整理等等），Browser Process 需要通知 renderer Process 進行相關的檢查，對相關事件進行處理。
如果導航由 renderer process 觸發（比如在使用者點選某連結，或者JS執行 `window.location = "http://newsite.com" ` ） renderer process 會首先檢查是否有 `beforeunload` 事件處理器，導航請求由 renderer process 傳遞給 Browser process
如果導航到新的網站，會啟用一個新的 render process 來處理新頁面的渲染，老的程序會留下來處理類似 `unload` 等事件。
關於頁面的生命週期，更多內容可參考Page Lifecycle API。
瀏覽器程序傳送 IPC 訊息到新的渲染程序通知渲染新的頁面，同時通知舊的渲染程序解除安裝除了上述流程，有些頁面還擁有 Service Worker （服務工作執行緒），Service Worker 讓開發者對本地快取及判斷何時從網路上獲取資訊有了更多的控制權，如果 Service Worker 被設定為從本地 cache 中載入資料，那麼就沒有必要從網上獲取更多資料了。
值得注意的是 service worker 也是執行在渲染程序中的 JS 程式碼，因此對於擁有 Service Worker 的頁面，上述流程有些許的不同。
當有 Service Worker 被註冊時，其作用域會被儲存，當有導航時，network thread 會在註冊過的 Service Worker 的作用域中檢查相關域名，如果存在對應的 Service worker，UI thread 會找到一個 renderer process 來處理相關程式碼，Service Worker 可能會從 cache 中載入資料，從而終止對網路的請求，也可能從網上請求新的資料。
Service Worker 依據具體情形做處理關於 Service Worker 的更多內容可參考The Service Worker Lifecycle
如果 Service Worker 最終決定通過網上獲取資料，Browser 程序 和 renderer 程序的互動其實會延後資料的請求時間 。Navigation Preload 是一種與 Service Worker 並行的加速載入資源的機制，服務端通過請求頭可以識別這類請求，而做出相應的處理。
更多內容可參考：Speed up Service Worker with Navigation Preloads
渲染程序是如何工作的
渲染程序幾乎負責 Tab 內的所有事情，渲染程序的核心目的在於轉換 HTML CSS JS 為使用者可互動的 web 頁面。渲染程序中主要包含以下執行緒：
渲染程序包含的執行緒- 主執行緒 Main thread
- 工作執行緒 Worker thread
- 排版執行緒 Compositor thread
- 光柵執行緒 Raster thread
後文我們將逐步介紹不同執行緒的職責，在此之前我們先看看渲染的流程
- 構建 DOM
當渲染程序接收到導航的確認資訊，開始接受 HTML 資料時，主執行緒會解析文字字串為 DOM。
渲染 html 為 DOM 的方法由HTML Standard定義。
2. 載入次級的資源
網頁中常常包含諸如圖片，CSS，JS 等額外的資源，這些資源需要從網路上或者 cache 中獲取。主程序可以在構建 DOM 的過程中會逐一請求它們，為了加速 preload scanner 會同時執行，如果在 html 中存在 `<img>` `<link>` 等標籤，preload scanner 會把這些請求傳遞給 Browser process 中的 network thread 進行相關資源的下載。
3. JS 的下載與執行
當遇到 `<script>` 標籤時，渲染程序會停止解析 HTML，而去載入，解析和執行 JS 程式碼，停止解析 html 的原因在於 JS 可能會改變 DOM 的結構（使用諸如 `document.write()`等API）。
不過開發者其實也有多種方式來告知瀏覽器應對如何應對某個資源，比如說如果在`<script>` 標籤上添加了 `async` 或 `defer` 等屬性，瀏覽器會非同步的載入和執行JS程式碼，而不會阻塞渲染。更多的方法可參考Resource Prioritization – Getting the Browser to Help You
4. 樣式計算
僅僅渲染 DOM 還不足以獲知頁面的具體樣式，主程序還會基於 CSS 選擇器解析 CSS 獲取每一個節點的最終的計算樣式值。即使不提供任何 CSS，瀏覽器對每個元素也會有一個預設的樣式。
渲染程序主執行緒計算每一個元素節點的最終樣式值5. 獲取佈局
想要渲染一個完整的頁面，除了獲知每個節點的具體樣式，還需要獲知每一個節點在頁面上的位置，佈局其實是找到所有元素的幾何關係的過程。其具體過程如下：
通過遍歷 DOM 及相關元素的計算樣式，主執行緒會構建出包含每個元素的座標資訊及盒子大小的佈局樹。佈局樹和 DOM 樹類似，但是其中只包含頁面可見的元素，如果一個元素設定了 `display:none` ，這個元素不會出現在佈局樹上，偽元素雖然在 DOM 樹上不可見，但是在佈局樹上是可見的。
主執行緒遍歷 DOM 及 對應元素的樣式，構建出佈局樹
6. 繪製各元素
即使知道了不同元素的位置及樣式資訊，我們還需要知道不同元素的繪製先後順序才能正確繪製出整個頁面。在繪製階段，主執行緒會遍歷佈局樹以建立繪製記錄。繪製記錄可以看做是記錄各元素繪製先後順序的筆記。
主執行緒依據佈局樹構建繪製記錄7. 合成幀
熟悉 PS 等繪圖軟體的童鞋肯定對圖層這一概念不陌生，現代 Chrome 其實利用了這一概念來組合不同的層。
複合是一種分割頁面為不同的層，並單獨柵格化，隨後組合為幀的技術。不同層的組合由 compositor 執行緒（合成器執行緒）完成。
主執行緒會遍歷佈局樹來建立層樹（layer tree），添加了 `will-change` CSS 屬性的元素，會被看做單獨的一層，
主執行緒遍歷佈局樹生成層樹你可能會想給每一個元素都新增上 `will-change`，不過組合過多的層也許會比在每一幀都柵格化頁面中的某些小部分更慢。為了更合理的使用層，可參考堅持僅合成器的屬性和管理層計數。
一旦層樹被建立，渲染順序被確定，主執行緒會把這些資訊通知給合成器執行緒，合成器執行緒會柵格化每一層。有的層的可以達到整個頁面的大小，因此，合成器執行緒將它們分成多個磁貼，並將每個磁貼傳送到柵格執行緒，柵格執行緒會柵格化每一個磁貼並存儲在 GPU 視訊記憶體中。
柵格執行緒會柵格化每一個磁貼並存儲在 GPU 視訊記憶體中一旦磁貼被光柵化，合成器執行緒會收集稱為繪製四邊形的磁貼資訊以建立合成幀。
合成幀隨後會通過 IPC 訊息傳遞給瀏覽器程序，由於瀏覽器的 UI 改變或者其它拓展的渲染程序也可以新增合成幀，這些合成幀會被傳遞給 GPU 用以展示在螢幕上，如果滾動發生，合成器執行緒會建立另一個合成幀傳送給 GPU。
合成器執行緒會發送合成幀給 GPU 渲染合成器的優點在於，其工作無關主執行緒，合成器執行緒不需要等待樣式計算或者 JS 執行，這就是為什麼合成器相關的動畫最流暢，如果某個動畫涉及到佈局或者繪製的調整，就會涉及到主執行緒的重新計算，自然會慢很多。
瀏覽器對事件的處理
瀏覽器通過對不同事件的處理來滿足各種互動需求，這一部分我們一起看看從瀏覽器的視角，事件是什麼，在此我們先主要考慮滑鼠事件。
在瀏覽器的看來，使用者的所有手勢都是輸入，滑鼠滾動，懸置，點選等等都是。
當用戶在螢幕上觸發諸如 touch 等手勢時，首先收到手勢資訊的是 Browser process， 不過 Browser process 只會感知到在哪裡發生了手勢，對 tab 內內容的處理是還是由渲染程序控制的。
事件發生時，瀏覽器程序會發送事件型別及相應的座標給渲染程序，渲染程序隨後找到事件物件並執行所有繫結在其上的相關事件處理函式。
事件從瀏覽器程序傳送給渲染程序前文中，我們提到過合成器可以獨立於主執行緒之外通過合成柵格化層平滑的處理滾動。如果頁面中沒有繫結相關事件，組合器執行緒可以獨立於主執行緒建立組合幀。如果頁面綁定了相關事件處理器，主執行緒就不得不出來工作了。這時候合成器執行緒會怎麼處理呢？
這裡涉及到一個專業名詞「理解非快速滾動區域（non-fast scrollable region）」由於執行 JS 是主執行緒的工作，當頁面合成時，合成器執行緒會標記頁面中繫結有事件處理器的區域為 non-fast scrollable region ，如果存在這個標註，合成器執行緒會把發生在此處的事件傳送給主執行緒，如果事件不是發生在這些區域，合成器執行緒則會直接合成新的幀而不用等到主執行緒的響應。
涉及 non-fast scrollable region 的事件，合成器執行緒會通知主執行緒進行相關處理web 開發中常用的事件處理模式是事件委託，基於事件冒泡，我們常常在最頂層繫結事件：
document.body.addEventListener('touchstart',
event => {
if (event.target === area) {
event.preventDefault();
}
}
);
上述做法很常見，但是如果從瀏覽器的角度看，整個頁面都成了 non-fast scrollable region 了。
這意味著即使操作的是頁面無繫結事件處理器的區域，每次輸入時，合成器執行緒也需要和主執行緒通訊並等待反饋，流暢的合成器獨立處理合成幀的模式就失效了。
由於事件繫結在最頂部，整個頁面都成為了 non-fast scrollable region為了防止這種情況，我們可以為事件處理器傳遞 `passive: true` 做為引數，這樣寫就能讓瀏覽器即監聽相關事件，又讓組合器執行緒在等等主執行緒響應前構建新的組合幀。
document.body.addEventListener('touchstart',
event => {
if (event.target === area) {
event.preventDefault()
}
}, {passive: true}
);
不過上述寫法可能又會帶來另外一個問題，假設某個區域你只想要水平滾動，使用 `passive: true` 可以實現平滑滾動，但是垂直方向的滾動可能會先於`event.preventDefault()`發生，此時可以通過 `event.cancelable` 來防止這種情況。
document.body.addEventListener('pointermove', event => {
if (event.cancelable) {
event.preventDefault(); // block the native scroll
/*
* do what you want the application to do here
*/
}
}, {passive: true});
也可以使用css屬性 `touch-action` 來完全消除事件處理器的影響，如：
#area {
touch-action: pan-x;
}查詢到事件物件
當組合器執行緒傳送輸入事件給主執行緒時，主執行緒首先會進行命中測試（hit test）來查詢對應的事件目標，命中測試會基於渲染過程中生成的繪製記錄（ paint records ）查詢事件發生座標下存在的元素。
主執行緒依據繪製記錄查詢事件相關元素事件的優化
一般我們螢幕的重新整理速率為 60fps，但是某些事件的觸發量會不止這個值，出於優化的目的，Chrome 會合並連續的事件(如 wheel, mousewheel, mousemove, pointermove, touchmove )，並延遲到下一幀渲染時候執行 。
而如 keydown, keyup, mouseup, mousedown, touchstart, 和 touchend 等非連續性事件則會立即被觸發。
Chrome 會合並連續事件到下一幀觸發合併事件雖然能提示效能，但是如果你的應用是繪畫等，則很難繪製一條平滑的曲線了，此時可以使用 `getCoalescedEvents` API 來獲取組合的事件。示例程式碼如下：
window.addEventListener('pointermove', event => {
const events = event.getCoalescedEvents();
for (let event of events) {
const x = event.pageX;
const y = event.pageY;
// draw a line using x and y coordinates.
}
});
花了好久來整理上面的內容，整理的過程收穫還挺大的，也希望這篇筆記能對你有所啟發，如果有任何疑問，歡迎一起來討論。
相關參考連結
- CPU, GPU, Memory, and multi-process architecture
- What happens in navigation
- Inner workings of a Renderer Process
- Input is coming to the Compositor
- 瀏覽器的工作原理：新式網路瀏覽器幕後揭祕