你不知道的瀏覽器渲染原理

原文地址： https://segmentfault.com/a/1190000022633988?_ea=44436475#item-4-8

作者：楊溜溜

在我們面試過程中，面試官經常會問到這麼一個問題，那就是從在瀏覽器地址欄中輸入 URL 到頁面顯示，瀏覽器到底發生了什麼？這個問題看起來是老生常談，但是這個問題回答的好壞，確實可以很好的反映出面試者知識的廣度和深度。

本文從瀏覽器角度來告訴你，URL 後輸入後按回車，瀏覽器內部究竟發生了什麼，讀完本文後，你將瞭解到：

我們與瀏覽器交互時，內部進程是怎麼處理這些交互事件的

在講瀏覽器架構之前，先理解兩個概念，進程和線程。

進程（process）是程序的一次執行過程，是一個動態概念，是程序在執行過程中分配和管理資源的基本單位，線程（thread）是 CPU 調度和分派的基本單位，它可與同屬一個進程的其他的線程共享進程所擁有的全部資源。

簡單的說呢，進程可以理解成正在執行的應用程序，而線程呢，可以理解成我們應用程序中的代碼的執行器。而他們的關係可想而知，線程是跑在進程裏面的，一個進程裏面可能有一個或者多個線程，而一個線程，只能隸屬於一個進程。

大家都知道，瀏覽器屬於一個應用程序，而應用程序的一次執行，可以理解爲計算機啓動了一個進程，進程啓動後，CPU 會給該進程分配相應的內存空間，當我們的進程得到了內存之後，就可以使用線程進行資源調度，進而完成我們應用程序的功能。

而在應用程序中，爲了滿足功能的需要，啓動的進程會創建另外的新的進程來處理其他任務，這些創建出來的新的進程擁有全新的獨立的內存空間，不能與原來的進程內向內存，如果這些進程之間需要通信，可以通過 IPC 機制（Inter Process Communication）來進行。

很多應用程序都會採取這種多進程的方式來工作，因爲進程和進程之間是互相獨立的它們互不影響，也就是說，當其中一個進程掛掉了之後，不會影響到其他進程的執行，只需要重啓掛掉的進程就可以恢復運行。

瀏覽器的多進程架構

假如我們去開發一個瀏覽器，它的架構可以是一個單進程多線程的應用程序，也可以是一個使用 IPC 通信的多進程應用程序。

不同的瀏覽器使用不同的架構，下面主要以 Chrome 爲例，介紹瀏覽器的多進程架構。

在 Chrome 中，主要的進程有 4 個：

瀏覽器進程 (Browser Process)：負責瀏覽器的 TAB 的前進、後退、地址欄、書籤欄的工作和處理瀏覽器的一些不可見的底層操作，比如網絡請求和文件訪問。
渲染進程 (Renderer Process)：負責一個 Tab 內的顯示相關的工作，也稱渲染引擎。
插件進程 (Plugin Process)：負責控制網頁使用到的插件
GPU 進程 (GPU Process)：負責處理整個應用程序的 GPU 任務

這 4 個進程之間的關係是什麼呢？

首先，當我們是要瀏覽一個網頁，我們會在瀏覽器的地址欄裏輸入 URL，這個時候Browser Process會向這個 URL 發送請求，獲取這個 URL 的 HTML 內容，然後將 HTML 交給Renderer Process，Renderer Process解析 HTML 內容，解析遇到需要請求網絡的資源又返回來交給Browser Process進行加載，同時通知Browser Process，需要Plugin Process加載插件資源，執行插件代碼。解析完成後，Renderer Process計算得到圖像幀，並將這些圖像幀交給GPU Process，GPU Process將其轉化爲圖像顯示屏幕。

多進程架構的好處

Chrome 爲什麼要使用多進程架構呢？

第一，更高的容錯性。當今 WEB 應用中，HTML，JavaScript 和 CSS 日益複雜，這些跑在渲染引擎的代碼，頻繁的出現 BUG，而有些 BUG 會直接導致渲染引擎崩潰，多進程架構使得每一個渲染引擎運行在各自的進程中，相互之間不受影響，也就是說，當其中一個頁面崩潰掛掉之後，其他頁面還可以正常的運行不收影響。

第二，更高的安全性和沙盒性（sanboxing）。渲染引擎會經常性的在網絡上遇到不可信、甚至是惡意的代碼，它們會利用這些漏洞在你的電腦上安裝惡意的軟件，針對這一問題，瀏覽器對不同進程限制了不同的權限，併爲其提供沙盒運行環境，使其更安全更可靠

第三，更高的響應速度。在單進程的架構中，各個任務相互競爭搶奪 CPU 資源，使得瀏覽器響應速度變慢，而多進程架構正好規避了這一缺點。

多進程架構優化

之前的我們說到，Renderer Process的作用是負責一個 Tab 內的顯示相關的工作，這就意味着，一個 Tab，就會有一個 Renderer Process，這些進程之間的內存無法進行共享，而不同進程的內存常常需要包含相同的內容。

瀏覽器的進程模式

爲了節省內存，Chrome 提供了四種進程模式（Process Models），不同的進程模式會對 tab 進程做不同的處理。

Process-per-site-instance (default) - 同一個 site-instance 使用一個進程
Process-per-site - 同一個 site 使用一個進程
Process-per-tab - 每個 tab 使用一個進程
Single process - 所有 tab 共用一個進程

這裏需要給出 site 和 site-instance 的定義

site 指的是相同的 registered domain name(如：google.com ，bbc.co.uk) 和 scheme (如：https://)。比如 a.baidu.com 和 b.baidu.com 就可以理解爲同一個 site（注意這裏要和 Same-origin policy 區分開來，同源策略還涉及到子域名和端口）。
site-instance 指的是一組 connected pages from the same site，這裏 connected 的定義是 can obtain references to each other in script code 怎麼理解這段話呢。滿足下面兩中情況並且打開的新頁面和舊頁面屬於上面定義的同一個 site，就屬於同一個 site-instance
用戶通過<a target="_blank">這種方式點擊打開的新頁面
JS 代碼打開的新頁面（比如 window.open)

理解了概念之後，下面解釋四個進程模式

首先是Single process，顧名思義，單進程模式，所有 tab 都會使用同一個進程。接下來是Process-per-tab ，也是顧名思義，每打開一個 tab，會新建一個進程。而對於Process-per-site，當你打開 a.baidu.com 頁面，在打開 b.baidu.com 的頁面，這兩個頁面的 tab 使用的是共一個進程，因爲這兩個頁面的 site 相同，而如此一來，如果其中一個 tab 崩潰了，而另一個 tab 也會崩潰。

Process-per-site-instance 是最重要的，因爲這個是 Chrome 默認使用的模式，也就是幾乎所有的用戶都在用的模式。當你打開一個 tab 訪問 a.baidu.com ，然後再打開一個 tab 訪問 b.baidu.com，這兩個 tab 會使用兩個進程。而如果你在 a.baidu.com 中，通過 JS 代碼打開了 b.baidu.com 頁面，這兩個 tab 會使用同一個進程。

默認模式選擇

那麼爲什麼瀏覽器使用Process-per-site-instance作爲默認的進程模式呢？

Process-per-site-instance兼容了性能與易用性，是一個比較中庸通用的模式。

相較於 Process-per-tab，能夠少開很多進程，就意味着更少的內存佔用
相較於 Process-per-site，能夠更好的隔離相同域名下毫無關聯的 tab，更加安全

導航過程都發生了什麼

前面我們講了瀏覽器的多進程架構，講了多進程架構的各種好處，和 Chrome 是怎麼優化多進程架構的，下面從用戶瀏覽網頁這一簡單的場景，來深入瞭解進程和線程是如何呈現我們的網站頁面的。

網頁加載過程

之前我們我們提到，tab 以外的大部分工作由瀏覽器進程Browser Process負責，針對工作的不同，Browser Process 劃分出不同的工作線程：

UI thread：控制瀏覽器上的按鈕及輸入框；
network thread：處理網絡請求，從網上獲取數據；
storage thread：控制文件等的訪問；

第一步：處理輸入

當我們在瀏覽器的地址欄輸入內容按下回車時，UI thread會判斷輸入的內容是搜索關鍵詞（search query）還是 URL，如果是搜索關鍵詞，跳轉至默認搜索引擎對應都搜索 URL，如果輸入的內容是 URL，則開始請求 URL。

第二步：開始導航

回車按下後，UI thread將關鍵詞搜索對應的 URL 或輸入的 URL 交給網絡線程Network thread，此時 UI 線程使 Tab 前的圖標展示爲加載中狀態，然後網絡進程進行一系列諸如 DNS 尋址，建立 TLS 連接等操作進行資源請求，如果收到服務器的 301 重定向響應，它就會告知 UI 線程進行重定向然後它會再次發起一個新的網絡請求。

第三步：讀取響應

第四步：查找渲染進程

各種檢查完畢以後，network thread 確信瀏覽器可以導航到請求網頁，network thread 會通知 UI thread 數據已經準備好，UI thread 會查找到一個 renderer process 進行網頁的渲染。

第五步：提交導航

到了這一步，數據和渲染進程都準備好了，Browser Process 會向 Renderer Process 發送 IPC 消息來確認導航，此時，瀏覽器進程將準備好的數據發送給渲染進程，渲染進程接收到數據之後，又發送 IPC 消息給瀏覽器進程，告訴瀏覽器進程導航已經提交了，頁面開始加載。

這個時候導航欄會更新，安全指示符更新（地址前面的小鎖），訪問歷史列表（history tab）更新，即可以通過前進後退來切換該頁面。

第六步：初始化加載完成

當導航提交完成後，渲染進程開始加載資源及渲染頁面（詳細內容下文介紹），當頁面渲染完成後（頁面及內部的 iframe 都觸發了 onload 事件），會向瀏覽器進程發送 IPC 消息，告知瀏覽器進程，這個時候 UI thread 會停止展示 tab 中的加載中圖標。

網頁渲染原理

導航過程完成之後，瀏覽器進程把數據交給了渲染進程，渲染進程負責 tab 內的所有事情，核心目的就是將 HTML/CSS/JS 代碼，轉化爲用戶可進行交互的 web 頁面。那麼渲染進程是如何工作的呢？

渲染進程中，包含線程分別是：

一個主線程（main thread）
多個工作線程（work thread）
一個合成器線程（compositor thread）
多個光柵化線程（raster thread）

不同的線程，有着不同的工作職責。

構建 DOM

當渲染進程接受到導航的確認信息後，開始接受來自瀏覽器進程的數據，這個時候，主線程會解析數據轉化爲 DOM（Document Object Model）對象。

DOM 爲 WEB 開發人員通過 JavaScript 與網頁進行交互的數據結構及 API。

資源子加載

在構建 DOM 的過程中，會解析到圖片、CSS、JavaScript 腳本等資源，這些資源是需要從網絡或者緩存中獲取的，主線程在構建 DOM 過程中如果遇到了這些資源，逐一發起請求去獲取，而爲了提升效率，瀏覽器也會運行預加載掃描（preload scanner）程序，如果如果 HTML 中存在img、link等標籤，預加載掃描程序會把這些請求傳遞給Browser Process的 network thread 進行資源下載。

JavaScript 的下載與執行

構建 DOM 過程中，如果遇到<script>標籤，渲染引擎會停止對 HTML 的解析，而去加載執行 JS 代碼，原因在於 JS 代碼可能會改變 DOM 的結構（比如執行document.write()等 API）

不過開發者其實也有多種方式來告知瀏覽器應對如何應對某個資源，比如說如果在<script> 標籤上添加了 async 或 defer 等屬性，瀏覽器會異步的加載和執行 JS 代碼，而不會阻塞渲染。

樣式計算 - Style calculation

DOM 樹只是我們頁面的結構，我們要知道頁面長什麼樣子，我們還需要知道 DOM 的每一個節點的樣式。主線程在解析頁面時，遇到<style>標籤或者<link>標籤的 CSS 資源，會加載 CSS 代碼，根據 CSS 代碼確定每個 DOM 節點的計算樣式（computed style）。

計算樣式是主線程根據 CSS 樣式選擇器（CSS selectors）計算出的每個 DOM 元素應該具備的具體樣式，即使你的頁面沒有設置任何自定義的樣式，瀏覽器也會提供其默認的樣式。

佈局 - Layout

DOM 樹和計算樣式完成後，我們還需要知道每一個節點在頁面上的位置，佈局（Layout）其實就是找到所有元素的幾何關係的過程。

主線程會遍歷 DOM 及相關元素的計算樣式，構建出包含每個元素的頁面座標信息及盒子模型大小的佈局樹（Render Tree），遍歷過程中，會跳過隱藏的元素（display: none），另外，僞元素雖然在 DOM 上不可見，但是在佈局樹上是可見的。

繪製 - Paint

佈局 layout 之後，我們知道了不同元素的結構，樣式，幾何關係，我們要繪製出一個頁面，我們要需要知道每個元素的繪製先後順序，在繪製階段，主線程會遍歷佈局樹（layout tree），生成一系列的繪畫記錄（paint records）。繪畫記錄可以看做是記錄各元素繪製先後順序的筆記。

合成 - Compositing

文檔結構、元素的樣式、元素的幾何關係、繪畫順序，這些信息我們都有了，這個時候如果要繪製一個頁面，我們需要做的是把這些信息轉化爲顯示器中的像素，這個轉化的過程，叫做光柵化（rasterizing）。

那我們要繪製一個頁面，最簡單的做法是隻光柵化視口內（viewport）的網頁內容，如果用戶進行了頁面滾動，就移動光柵幀（rastered frame）並且光柵化更多的內容以補上頁面缺失的部分，如下：

Chrome 第一個版本就是採用這種簡單的繪製方式，這一方式唯一的缺點就是每當頁面滾動，光柵線程都需要對新移進視圖的內容進行光柵化，這是一定的性能損耗，爲了優化這種情況，Chrome 採取一種更加複雜的叫做合成（compositing）的做法。

那麼，什麼是合成？合成是一種將頁面分成若干層，然後分別對它們進行光柵化，最後在一個單獨的線程 - 合成線程（compositor thread）裏面合併成一個頁面的技術。當用戶滾動頁面時，由於頁面各個層都已經被光柵化了，瀏覽器需要做的只是合成一個新的幀來展示滾動後的效果罷了。頁面的動畫效果實現也是類似，將頁面上的層進行移動並構建出一個新的幀即可。

爲了實現合成技術，我們需要對元素進行分層，確定哪些元素需要放置在哪一層，主線程需要遍歷渲染樹來創建一棵層次樹（Layer Tree），對於添加了 will-change CSS 屬性的元素，會被看做單獨的一層，沒有 will-change CSS 屬性的元素，瀏覽器會根據情況決定是否要把該元素放在單獨的層。

你可能會想要給頁面上所有的元素一個單獨的層，然而當頁面的層超過一定的數量後，層的合成操作要比在每個幀中光柵化頁面的一小部分還要慢，因此衡量你應用的渲染性能是十分重要的一件事情。

一旦 Layer Tress 被創建，渲染順序被確定，主線程會把這些信息通知給合成器線程，合成器線程開始對層次數的每一層進行光柵化。有的層的可以達到整個頁面的大小，所以合成線程需要將它們切分爲一塊又一塊的小圖塊（tiles），之後將這些小圖塊分別進行發送給一系列光柵線程（raster threads）進行光柵化，結束後光柵線程會將每個圖塊的光柵結果存在GPU Process的內存中。

爲了優化顯示體驗，合成線程可以給不同的光柵線程賦予不同的優先級，將那些在視口中的或者視口附近的層先被光柵化。

當圖層上面的圖塊都被柵格化後，合成線程會收集圖塊上面叫做繪畫四邊形（draw quads）的信息來構建一個合成幀（compositor frame）。

繪畫四邊形：包含圖塊在內存的位置以及圖層合成後圖塊在頁面的位置之類的信息。
合成幀：代表頁面一個幀的內容的繪製四邊形集合。

以上所有步驟完成後，合成線程就會通過 IPC 向瀏覽器進程（browser process）提交（commit）一個渲染幀。這個時候可能有另外一個合成幀被瀏覽器進程的 UI 線程（UI thread）提交以改變瀏覽器的 UI。這些合成幀都會被髮送給 GPU 從而展示在屏幕上。如果合成線程收到頁面滾動的事件，合成線程會構建另外一個合成幀發送給 GPU 來更新頁面。

合成的好處在於這個過程沒有涉及到主線程，所以合成線程不需要等待樣式的計算以及 JavaScript 完成執行。這就是爲什麼合成器相關的動畫最流暢，如果某個動畫涉及到佈局或者繪製的調整，就會涉及到主線程的重新計算，自然會慢很多。

瀏覽器對事件的處理

當頁面渲染完畢以後，TAB 內已經顯示出了可交互的 WEB 頁面，用戶可以進行移動鼠標、點擊頁面等操作了，而當這些事件發生時候，瀏覽器是如何處理這些事件的呢？

以點擊事件（click event）爲例，讓鼠標點擊頁面時候，首先接受到事件信息的是Browser Process，但是 Browser Process 只知道事件發生的類型和發生的位置，具體怎麼對這個點擊事件進行處理，還是由 Tab 內的Renderer Process進行的。Browser Process 接受到事件後，隨後便把事件的信息傳遞給了渲染進程，渲染進程會找到根據事件發生的座標，找到目標對象（target），並且運行這個目標對象的點擊事件綁定的監聽函數（listener）。

渲染進程中合成器線程接收事件

前面我們說到，合成器線程可以獨立於主線程之外通過已光柵化的層創建組合幀，例如頁面滾動，如果沒有對頁面滾動綁定相關的事件，組合器線程可以獨立於主線程創建組合幀，如果頁面綁定了頁面滾動事件，合成器線程會等待主線程進行事件處理後纔會創建組合幀。那麼，合成器線程是如何判斷出這個事件是否需要路由給主線程處理的呢？

由於執行 JS 是主線程的工作，當頁面合成時，合成器線程會標記頁面中綁定有事件處理器的區域爲非快速滾動區域(non-fast scrollable region)，如果事件發生在這些存在標註的區域，合成器線程會把事件信息發送給主線程，等待主線程進行事件處理，如果事件不是發生在這些區域，合成器線程則會直接合成新的幀而不用等到主線程的響應。

而對於非快速滾動區域的標記，開發者需要注意全局事件的綁定，比如我們使用事件委託，將目標元素的事件交給根元素 body 進行處理，代碼如下：

在開發者角度看，這一段代碼沒什麼問題，但是從瀏覽器角度看，這一段代碼給 body 元素綁定了事件監聽器，也就意味着整個頁面都被編輯爲一個非快速滾動區域，這會使得即使你的頁面的某些區域沒有綁定任何事件，每次用戶觸發事件時，合成器線程也需要和主線程通信並等待反饋，流暢的合成器獨立處理合成幀的模式就失效了。

其實這種情況也很好處理，只需要在事件監聽時傳遞passtive參數爲 true，passtive會告訴瀏覽器你既要綁定事件，又要讓組合器線程直接跳過主線程的事件處理直接合成創建組合幀。

document.body.addEventListener('touchstart', event => {
    if (event.target === area) {
        event.preventDefault()
    }
 }, {passive: true});

查找事件的目標對象（event target）

當合成器線程接收到事件信息，判定到事件發生不在非快速滾動區域後，合成器線程會向主線程發送這個時間信息，主線程獲取到事件信息的第一件事就是通過命中測試（hit test）去找到事件的目標對象。具體的命中測試流程是遍歷在繪製階段生成的繪畫記錄（paint records）來找到包含了事件發生座標上的元素對象。

瀏覽器對事件的優化

一般我們屏幕的幀率是每秒 60 幀，也就是 60fps，但是某些事件觸發的頻率超過了這個數值，比如 wheel，mousewheel，mousemove，pointermove，touchmove，這些連續性的事件一般每秒會觸發 60~120 次，假如每一次觸發事件都將事件發送到主線程處理，由於屏幕的刷新速率相對來說較低，這樣使得主線程會觸發過量的命中測試以及 JS 代碼，使得性能有了沒必要是損耗。

出於優化的目的，瀏覽器會合並這些連續的事件，延遲到下一幀渲染是執行，也就是requestAnimationFrame之前。

而對於非連續性的事件，如 keydown，keyup，mousedown，mouseup，touchstart，touchend 等，會直接派發給主線程去執行。

總結

瀏覽器的多進程架構，根據不同的功能劃分了不同的進程，進程內不同的使命劃分了不同的線程，當用戶開始瀏覽網頁時候，瀏覽器進程進行處理輸入、開始導航請求數據、請求響應數據，查找新建渲染進程，提交導航，之後渲染又進行了解析 HTML 構建 DOM、構建過程加載子資源、下載並執行 JS 代碼、樣式計算、佈局、繪製、合成，一步一步的構建出一個可交互的 WEB 頁面，之後瀏覽器進程又接受頁面的交互事件信息，並將其交給渲染進程，渲染進程內主進程進行命中測試，查找目標元素並執行綁定的事件，完成頁面的交互。

本文大部分內容也是對 inside look at modern web browser 系列文章的整理、解讀和翻譯吧，整理過程還是收穫非常大的，希望讀者讀了本文只有有所啓發吧。