一文看透瀏覽器架構

本文由雲+社區發表 做者：廖彩明

在從事前端開發過程當中，瀏覽器做爲最重要的開發環境，瀏覽器基礎是是前端開發人員必須掌握的基礎知識點，它貫穿着前端的整個網絡體系。對瀏覽器原理的瞭解，決定着編寫前端代碼性能的上限。瀏覽器做爲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 groups.google.com/a/chromium.…!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是單獨的渲染進程

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號