一文看透瀏覽器架構

> 本文由雲 + 社群發表 > 作者：廖彩明

在從事前端開發過程中，瀏覽器作為最重要的開發環境，瀏覽器基礎是是前端開發人員必須掌握的基礎知識點，它貫穿著前端的整個網路體系。對瀏覽器原理的瞭解，決定著編寫前端程式碼效能的上限。瀏覽器作為 JS 的執行環境，學習總結下現代瀏覽器的相關知識

前言

經常聽說瀏覽器核心，瀏覽器核心究竟是什麼，以及它做了什麼。我們將來了解下瀏覽器的主要組成部分、現代瀏覽器的主要架構、瀏覽器核心、瀏覽器內部是如何工作的

1 瀏覽器

現代瀏覽器結構如下：

The browser's main component

The User Interface

> 主要提供使用者與 Browser Engine 互動的方法。其中包括：位址列 (address bar)、向前/退後按鈕、書籤選單等等。瀏覽器除了渲染請求頁面的視窗外的所有地方都屬於 The User Interface

The Browser Engine

> 協調（主控）UI 和 the Rendering Engine，在他們之間傳輸指令。 提供對 The Rendering Engine 的高階介面，一方面它提供初始化載入 Url 和其他高階的瀏覽器動作（如重新整理、向前、退後等）方法。另一方面 Browser Engine 也為 User Interface 提供各種與錯誤、載入進度相關的訊息。

The Rendering Engine

> 為給定的 URL 提供視覺化的展示。它解析 JavaScript、Html、Xml，並且 User Interface 中展示的 layout。其中關鍵的元件是 Html 解析器，它可以讓 Rendering Engine 展示差亂的 Html 頁面。 值得注意：不同的瀏覽器使用不同的 Rendering Engine。例如 IE 使用 Trident，Firefox 使用 Gecko，Safai 使用 Webkit。Chrome 和 Opera 使用 Webkit（以前是 Blink）

The Networking

> 基於網際網路 HTTP 和 FTP 協議，處理網路請求。網路模組負責 Internet communication and security，character set translations and MIME type resolution。另外網路模組還提供獲得到文件的快取，以減少網路傳輸。為所有平臺提供底層網路實現，其提供的介面與平臺無關

The JavaScript Interpreter

> 解釋和執行網站上的 js 程式碼，得到的結果傳輸到 Rendering Engine 來展示。

The UI Backend

> 用於繪製基本的視窗小部件，比如組合框和視窗。而在底層使用作業系統的使用者介面方法，並公開與平臺無關的介面。

The Data Storage

> 管理使用者資料，例如書籤、cookie 和偏好設定等。

2 主流瀏覽器的架構

2.1 FireFox

FireFox 的架構

可以看到火狐瀏覽器的渲染引擎（Rendering Engine）使用的是 Gecko；XML Parser 解析器是 Expat；Java Script 直譯器是 Spider-Monkey（c 語言實現）

2.2 Chrome

Chrome 的架構

渲染引擎 Rendering Engine 使用的是 WebKit

XML Parser： libXML 解析 XML，libXSLT 處理 XSLT

JS 直譯器使用 C++ 實現的 V8 引擎，

2.3 IE

IE 的架構

渲染引擎主要是 Trident

Scripting Engine 有 JScript 和 VBScript

3 瀏覽器核心

瀏覽器最重要或者說核心的部分是 “Rendering Engine”，可大概譯為 “渲染引擎”，不過我們一般習慣將之稱為 “瀏覽器核心”。主要包括以下執行緒：

3.1 瀏覽器 GUI 渲染執行緒，主要包括：

>  HTML Parser 解析 HTML 文件，將元素轉換為樹結構 DOM 節點，稱之為 Content Tree > >  CSS Parser 解析 Style 資料，包括外部的 CSS 檔案以及在 HTML 元素中的樣式，用於建立另一棵樹，呼叫 “Render Tree” > >  Layout 過程 為每個節點計算出在螢幕中展示的準確座標 > >  Painting 遍歷 Render Tree，呼叫 UI Backend 提供的介面繪製每個節點

3.2 JavaScript 引擎執行緒

> JS 引擎執行緒負責解析 Javascript 指令碼，執行程式碼 JS 引擎一直等待著任務佇列中任務的到來，然後加以處理，一個 Tab 頁（renderer 程式）中無論什麼時候都只有一個 JS 執行緒在執行 JS 程式

GUI 渲染執行緒與 JS 引擎執行緒是互斥的，所以如果 JS 執行的時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染載入阻塞

a) 減少 JavaScript 載入對 DOM 渲染的影響（將 JavaScript 程式碼的載入邏輯放在 HTML 檔案的尾部，減少對渲染引擎呈現工作的影響；
b) 避免重排，減少重繪（避免白屏，或者互動過程中的卡頓；
c) 減少 DOM 的層級（可以減少渲染引擎工作過程中的計算量；
d) 使用 requestAnimationFrame 來實現視覺變化（一般來說我們會使用 setTimeout 或 setInterval 來執行動畫之類的視覺變化，但這種做法的問題是，回撥將在幀中的某個時點執行，可能剛好在末尾，而這可能經常會使我們丟失幀，導致卡頓）

3.3 瀏覽器定時觸發器執行緒

> 瀏覽器定時計數器並不是由 JavaScript 引擎計數的, 因為 JavaScript 引擎是單執行緒的, 如果處於阻塞執行緒狀態就會影響記計時的準確, 因此通過單獨執行緒來計時並觸發定時是更為合理的方案

3.4 瀏覽器事件觸發執行緒

> 當一個事件被觸發時該執行緒會把事件新增到待處理佇列的隊尾，等待 JavaScript 引擎的處理。這些事件可以是當前執行的程式碼塊如定時任務、也可來自瀏覽器核心的其他執行緒如滑鼠點選、AJAX 非同步請求等，但由於 JavaScript 的單執行緒關係所有這些事件都得排隊等待 JavaScript 引擎處理。

3.5 瀏覽器 http 非同步請求執行緒

> 在 XMLHttpRequest 在連線後是通過瀏覽器新開一個執行緒請求， 將檢測到狀態變更時，如果設定有回撥函式，非同步執行緒就產生狀態變更事件放到 JavaScript 引擎的處理佇列中等待處理。

4 以 Chrome 瀏覽器為例，演示瀏覽器內部如何工作

上面鋪墊了這麼多理論，下面結合 Chrome 講解當使用者在位址列上輸入 URL 後，瀏覽器內部都做了寫什麼

4.1 Chrome 瀏覽器中的多程式

開啟 Chrome 工作管理員，可以看到

Chrome 執行的程式

各個程式的功能

• Browser 程式

> 功能：Controls "chrome" part of the application including address bar, bookmarks, back and forward buttons. Also handles the invisible, privileged parts of a web browser such as network requests and file access.

• GPU 程式

> 功能：Handles GPU tasks in isolation from other processes. It is separated into different process because GPUs handles requests from multiple apps and draw them in the same surface.

• 第三方外掛程式

> 功能：Controls any plugins used by the website, for example, flash. 每個外掛對應一個程式，當外掛執行時建立

• 瀏覽器渲染程式

> 功能：Controls anything inside of the tab where a website is displayed. 預設每個標籤頁建立一個渲染引擎例項。

• V8 Proxy resolver

> 關於 V8 Proxy resolver 可檢視

code.google.com

group.google.com <https://groups.google.com/a/chromium.org/forum/#&gt! topic/net-dev/73f9B5vFphI;

doc.google.com

Chrome 支援使用代理指令碼為給定的網址選擇代理伺服器，包含使用作業系統提供的代理解析程式的多個平臺的回退實現。但預設情況下（iOS 除外），它使用內建的解析 V8 執行代理指令碼（V8 pac）。今天（截至 2015 年 1 月），V8 pac 在瀏覽器程式中執行。這意味著瀏覽器程式包含一個 V8 例項，這是一個潛在的安全漏洞。在瀏覽器程式中允許 V8 還需要瀏覽器程式允許寫入 - 執行頁面。

我們關於將 V8 pac 遷移到單獨程式的建議包括為解析器建立 Mojo 服務，從實用程式程式匯出該服務，以及從瀏覽器程式建立/連線到該程式。

瀏覽器程式之間主要通過 IPC (Inter Process Communication) 通訊

4.2 Per-frame renderer processes - Site Isolation

Site Isolation is a recently introduced feature in Chrome that runs a separate renderer process for each cross-site iframe. We’ve been talking about one renderer process per tab model which allowed cross-site iframes to run in a single renderer process with sharing memory space between different sites. Running a.com and b.com in the same renderer process might seem okay. The Same Origin Policy is the core security model of the web; it makes sure one site cannot access data from other sites without consent. Bypassing this policy is a primary goal of security attacks. Process isolation is the most effective way to separate sites. With Meltdown and Spectre, it became even more apparent that we need to separate sites using processes. With Site Isolation enabled on desktop by default since Chrome 67, each cross-site iframe in a tab gets a separate renderer process.

每個 iframe 是單獨的渲染程式

此文已由騰訊雲 + 社群在各渠道釋出

獲取更多新鮮技術乾貨，可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號