剖析瀏覽器渲染頁面的程序

瀏覽器的內部結構

從結構上來看，瀏覽器主要包括8個子系統

1. 用戶界面
2. 瀏覽器引擎
3. 渲染引擎
4. 網路子系統
5. JavaScript解釋器
6. XML解釋器
7. 顯示后端
8. 資料持久化子系統

這些子系統組合構成了我們的瀏覽器，頁面的加載和渲染程序，離不開網路子系統、渲染引擎、JavaScript 解釋器和瀏覽器引擎，

以前端開發最常使用的 Chrome 瀏覽器為例， Chrome 瀏覽器是使用多行程架構的方式來管理這些子系統，

Chrome 多行程架構

Chrome 瀏覽器采用的多行程架構，主要包括四個行程：

1. 瀏覽器行程：選項卡之外的所有內容都由瀏覽器行程處理，瀏覽器行程則主要用于控制和處理用戶可見的 UI 部分（包括地址欄，書簽，后退和前進按鈕）和用戶不可見的隱藏部分（例如網路請求和檔案訪問），

2. GPU 行程：該行程用于完成影像處理任務，同時還支持分解成多個行程進行處理，

3. 渲染器行程：Chrome 瀏覽器中支持多個選項卡，其中每個選項卡在單獨的渲染器行程中運行，渲染器行程主要用于控制和處理選項卡中的網站內容顯示，

4. 插件行程：管理 Chrome 瀏覽器中的各個插件，

對于“在瀏覽器的地址欄中輸入 URL，按下回車鍵，到瀏覽器渲染頁面”這個程序，瀏覽器內部會通過瀏覽器行程和渲染器行程，進行很多互動邏輯，最終才得以將頁面內容顯示在螢屏上，

其中，瀏覽器行程和渲染器行程同樣支持多執行緒，包括以下這些執行緒，

Chrome渲染器行程中的執行緒

• GUI渲染執行緒：負責對瀏覽器界面進行渲染
• JavaScript引擎執行緒：負責決議和執行JavaScript腳本
• 瀏覽器定時器觸發執行緒：setTimeout和setInterval方法所在執行緒
• 瀏覽器事件觸發執行緒：負責處理瀏覽器事件，并將事件觸發后需要執行的代碼放到JavaScript引擎中執行，

Chrome瀏覽器行程中的執行緒

• UI執行緒：用于繪制瀏覽器的按鈕和輸入欄位
• 網路執行緒：用于處理網路請求，以及從服務器接收資料
• 存盤執行緒：用于控制對檔案的訪問

這些執行緒其實并不陌生，在前面介紹的內容中有提到，比如：

在頁面的加載程序中，涉及 GUI 渲染執行緒與 JavaScript 引擎執行緒間的互斥關系，因此頁面中的

在 UI 執行緒、網路執行緒、存盤執行緒、瀏覽器事件觸發執行緒、瀏覽器定時器觸發執行緒中，I/O 事件通過異步任務完成時觸發的函式回呼，解決了單執行緒的 Javascript阻塞問題，

下面我們再來看下 Chrome 瀏覽器中頁面的渲染程序，包括瀏覽器行程和執行緒如何通信來顯示頁面，

瀏覽器中頁面的渲染程序

首先我們將瀏覽器中頁面的渲染程序分為兩部分，

• 頁面導航：用戶輸入 URL，瀏覽器行程進行請求和準備處理，

• 頁面渲染：獲取到相關資源后，渲染器行程負責選項卡內部的渲染處理，

1. 頁面導航程序

當用戶在地址欄中輸入內容時，瀏覽器內部會進行以下處理，

1. 首先瀏覽器行程的 UI 執行緒會進行處理：如果是 URI，則會發起網路請求來獲取網站內容；如果不是，則進入搜索引擎，
2. 如果需要發起網路請求，請求程序由網路執行緒來完成，HTTP 請求回應如果是 HTML 檔案，則將資料傳遞到渲染器行程；如果是其他檔案則意味著這是下載請求，此時會將資料傳遞到下載管理器，
3. 如果請求回應為 HTML 內容，此時瀏覽器應導航到請求站點，網路執行緒便通知 UI 執行緒資料準備就緒，
4. 接下來，UI 執行緒會尋找一個渲染器行程來進行網頁渲染，當資料和渲染器行程都準備好后，HTML 資料通過 IPC 從瀏覽器行程傳遞到渲染器行程中，
5. 渲染器行程接收 HTML 資料后，將開始加載資源并渲染頁面，
6. 渲染器行程完成渲染后，通過 IPC 通知瀏覽器行程頁面已加載，

以上是用戶在地址欄輸入網站地址，到頁面開始渲染的整體程序，為了方便理解，我幫你梳理了一個流程圖：

如果當前頁面跳轉到其他網站，瀏覽器將呼叫一個單獨的渲染行程來處理新導航，同時保留當前渲染行程來處理像unload這類事件，

在上面的程序中可以看到，頁面導航主要依賴瀏覽器行程，其中，上述程序中的步驟 5 便是頁面的渲染部分，該程序同樣依賴渲染器行程，我們一起來看看，

2. 頁面渲染程序

前面說過，渲染器行程負責選項卡內部發生的所有事情，它的核心作業是將 HTML、CSS 和 JavaScript 轉換為可互動的頁面，

整體上，渲染器行程渲染頁面的流程基本如下，

1. 決議(Parser)：決議 HTML/CSS/JavaScript 代碼，
2. 布局(Layout)：定位坐標和大小、是否換行、各種position/overflow/z-index屬性等計算，
3. 繪制(Paint)：判斷元素渲染層級順序，
4. 光柵化(Raster)：將計算后的資訊轉換為螢屏上的像素，

我們來分別看下，

1. 決議

渲染器行程的主執行緒會決議以下內容：

• 決議 HTML 內容，產生一個 DOM 節點樹；
• 決議 CSS，產生 CSS 規則樹；
• 決議 Javascript腳本，由于 Javascript腳本可以通過 DOM API 和 CSSOM API 來操作 DOM 節點樹和 CSS 規則樹，因此該程序中會等待 JavaScript 運行完成才繼續決議 HTML，

決議完成后，我們得到了 DOM 節點樹和 CSS 規則樹，布局程序便是通過 DOM 節點樹和 CSS 規則樹來構造渲染樹（Render Tree），

2. 布局

通過決議之后，渲染器行程知道每個節點的結構和樣式，但如果需要渲染頁面，瀏覽器還需要進行布局，布局程序便是我們常說的渲染樹的創建程序，

在這個程序中，像header或display:none的元素，它們會存在 DOM 節點樹中，但不會被添加到渲染樹里，

布局完成后，將會進入繪制環節，

3. 繪制

在繪制步驟中，渲染器主執行緒會遍歷渲染樹來創建繪制記錄，

需要注意的是，如果渲染樹發生了改變，則渲染器會觸發重繪（Repaint）和重排（Reflow），

重繪：螢屏的一部分要重畫，比如某個 CSS 的背景色變了，但是元素的幾何尺寸沒有變，

重排：元素的幾何尺寸變了（渲染樹的一部分或全部發生了變化），需要重新驗證并計算渲染樹，

為了不對每個小的變化都進行完整的布局計算，渲染器會將更改的元素和它的子元素進行臟位標記，表示該元素需要重新布局，其中，全域樣式更改會觸發全域布局，部分樣式或元素更改會觸發增量布局，增量布局是異步完成的，全域布局則會同步觸發，

重排需要涉及變更的所有的結點幾何尺寸和位置，成本比重繪的成本高得多的多，所以我們要注意以避免頻繁地進行增加、洗掉、修改 DOM 結點、移動 DOM 的位置、Resize 視窗、滾動等操作，因為這些操作可能會導致性能降低，

4. 光柵化

通過決議、布局和繪制程序，瀏覽器獲得了檔案的結構、每個元素的樣式、繪制順序等資訊，將這些資訊轉換為螢屏上的像素，這個程序被稱為光柵化，

光柵化可以被 GPU 加速，光柵化后的位圖會被存盤在 GPU 記憶體中，根據前面介紹的渲染流程，當頁面布局變更了會觸發重排和重繪，還需要重新進行光柵化，此時如果頁面中有影片，則主執行緒中過多的計算任務很可能會影響影片的性能，

因此，現代的瀏覽器通常使用合成的方式，將頁面的各個部分分成若干層，分別對其進行柵格化（將它們分割成了不同的瓦片），并通過合成器執行緒進行頁面的合成，

合成程序如下：

1. 當主執行緒創建了合成層并確定了繪制順序，便將這些資訊提交給合成執行緒；
2. 合成器執行緒將每個圖層柵格化，然后將每個圖塊發送給光柵執行緒；
3. 光柵執行緒柵格化每個瓦片，并將它們存盤在 GPU 記憶體中；
4. 合成器執行緒通過 IPC 提交給瀏覽器行程，這些合成器幀被發送到 GPU 行程處理，并顯示在螢屏上，

IPC：行程間通信

合成的真正目的是，在移動合成層的時候不用重新光柵化，因為有了合成器執行緒，頁面才可以獨立于主執行緒進行流暢的滾動，

到這里，頁面才真正渲染到螢屏上，

我們在繪制頁面的時候，也可能會遇到很多奇怪的渲染問題，比如使用了transform:scale可能會導致某些瀏覽器中渲染模糊，究其原因則是由于光柵化程序導致的，像前面所說，前端開發需要頻繁跟瀏覽器打交道，所謂知己知彼百戰不殆，我們應該對其運行程序有更好的了解，