深刻淺出瀏覽器渲染原理

時間 2019-11-13

原文原文鏈接

前言

瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分爲兩個部分的，一是渲染引擎，另外一個是JS引擎。渲染引擎在不一樣的瀏覽器中也不是都相同的。好比在 Firefox 中叫作 Gecko，在 Chrome 和 Safari 中都是基於 WebKit 開發的。本文咱們主要介紹關於 WebKit 的這部分渲染引擎內容以及幾個相關的問題。javascript

如需獲取思惟導圖請猛戳GitHub博客css

瀏覽器工做大致流程

瀏覽器工做流程大致分爲以下三部分：html

1）瀏覽器會解析三個東西：

一個是HTML/SVG/XHTML，事實上，Webkit有三個C++的類對應這三類文檔。解析這三種文件會產生一個DOM Tree。
CSS，解析CSS會產生CSS規則樹。
Javascript，腳本，主要是經過DOM API和CSSOM API來操做DOM Tree和CSS Rule Tree.

2）解析完成後，瀏覽器引擎會經過DOM Tree 和 CSS Rule Tree 來構造 Rendering Tree。

Rendering Tree 渲染樹並不等同於DOM樹，由於一些像Header或display:none的東西就不必放在渲染樹中了。
CSS 的 Rule Tree主要是爲了完成匹配並把CSS Rule附加上Rendering Tree上的每一個Element。也就是DOM結點。也就是所謂的Frame。
而後，計算每一個Frame（也就是每一個Element）的位置，這又叫layout和reflow過程。

3）最後經過調用操做系統Native GUI的API繪製。

接下來咱們針對這其中所經歷的重要步驟，一一詳細闡述。前端

構建DOM

瀏覽器會遵照一套步驟將HTML 文件轉換爲 DOM 樹。宏觀上，能夠分爲幾個步驟：java

瀏覽器從磁盤或網絡讀取HTML的原始字節，並根據文件的指定編碼（例如 UTF-8）將它們轉換成字符串。

在網絡中傳輸的內容其實都是 0 和 1 這些字節數據。當瀏覽器接收到這些字節數據之後，它會將這些字節數據轉換爲字符串，也就是咱們寫的代碼。node

將字符串轉換成Token，例如：<html>、<body>等。Token中會標識出當前Token是「開始標籤」或是「結束標籤」亦或是「文本」等信息。

這時候你必定會有疑問，節點與節點之間的關係如何維護？git

事實上，這就是Token要標識「起始標籤」和「結束標籤」等標識的做用。例如「title」Token的起始標籤和結束標籤之間的節點確定是屬於「head」的子節點。github

上圖給出了節點之間的關係，例如：「Hello」Token位於「title」開始標籤與「title」結束標籤之間，代表「Hello」Token是「title」Token的子節點。同理「title」Token是「head」Token的子節點。面試

生成節點對象並構建DOM

事實上，構建DOM的過程當中，不是等全部Token都轉換完成後再去生成節點對象，而是一邊生成Token一邊消耗Token來生成節點對象。換句話說，每一個Token被生成後，會馬上消耗這個Token建立出節點對象。注意：帶有結束標籤標識的Token不會建立節點對象。chrome

接下來咱們舉個例子，假設有段HTML文本：

<html>
<head>
    <title>Web page parsing</title>
</head>
<body>
    <div>
        <h1>Web page parsing</h1>
        <p>This is an example Web page.</p>
    </div>
</body>
</html>

上面這段HTML會解析成這樣：

構建CSSOM

DOM會捕獲頁面的內容，但瀏覽器還須要知道頁面如何展現，因此須要構建CSSOM。

構建CSSOM的過程與構建DOM的過程很是類似，當瀏覽器接收到一段CSS，瀏覽器首先要作的是識別出Token，而後構建節點並生成CSSOM。

在這一過程當中，瀏覽器會肯定下每個節點的樣式究竟是什麼，而且這一過程實際上是很消耗資源的。由於樣式你能夠自行設置給某個節點，也能夠經過繼承得到。在這一過程當中，瀏覽器得遞歸 CSSOM 樹，而後肯定具體的元素究竟是什麼樣式。

注意：CSS匹配HTML元素是一個至關複雜和有性能問題的事情。因此，DOM樹要小，CSS儘可能用id和class，千萬不要過渡層疊下去。

構建渲染樹

當咱們生成 DOM 樹和 CSSOM 樹之後，就須要將這兩棵樹組合爲渲染樹。

在這一過程當中，不是簡單的將二者合併就好了。渲染樹只會包括須要顯示的節點和這些節點的樣式信息，若是某個節點是 display: none 的，那麼就不會在渲染樹中顯示。

佈局與繪製

當瀏覽器生成渲染樹之後，就會根據渲染樹來進行佈局（也能夠叫作迴流）。這一階段瀏覽器要作的事情是要弄清楚各個節點在頁面中的確切位置和大小。一般這一行爲也被稱爲「自動重排」。

佈局流程的輸出是一個「盒模型」，它會精確地捕獲每一個元素在視口內的確切位置和尺寸，全部相對測量值都將轉換爲屏幕上的絕對像素。

佈局完成後，瀏覽器會當即發出「Paint Setup」和「Paint」事件，將渲染樹轉換成屏幕上的像素。

以上咱們詳細介紹了瀏覽器工做流程中的重要步驟，接下來咱們討論幾個相關的問題：

問題一：渲染過程當中遇到JS文件怎麼處理？

JavaScript的加載、解析與執行會阻塞DOM的構建，也就是說，在構建DOM時，HTML解析器若遇到了JavaScript，那麼它會暫停構建DOM，將控制權移交給JavaScript引擎，等JavaScript引擎運行完畢，瀏覽器再從中斷的地方恢復DOM構建。

也就是說，若是你想首屏渲染的越快，就越不該該在首屏就加載 JS 文件，這也是都建議將 script 標籤放在 body 標籤底部的緣由。固然在當下，並非說 script 標籤必須放在底部，由於你能夠給 script 標籤添加 defer 或者 async 屬性（下文會介紹這二者的區別）。

JS文件不僅是阻塞DOM的構建，它會致使CSSOM也阻塞DOM的構建。

本來DOM和CSSOM的構建是互不影響，井水不犯河水，可是一旦引入了JavaScript，CSSOM也開始阻塞DOM的構建，只有CSSOM構建完畢後，DOM再恢復DOM構建。

這是什麼狀況？

這是由於JavaScript不僅是能夠改DOM，它還能夠更改樣式，也就是它能夠更改CSSOM。前面咱們介紹，不完整的CSSOM是沒法使用的，但JavaScript中想訪問CSSOM並更改它，那麼在執行JavaScript時，必需要能拿到完整的CSSOM。因此就致使了一個現象，若是瀏覽器還沒有完成CSSOM的下載和構建，而咱們卻想在此時運行腳本，那麼瀏覽器將延遲腳本執行和DOM構建，直至其完成CSSOM的下載和構建。也就是說，在這種狀況下，瀏覽器會先下載和構建CSSOM，而後再執行JavaScript，最後在繼續構建DOM。

問題二：你真的瞭解迴流和重繪嗎

咱們知道，當網頁生成的時候，至少會渲染一次。在用戶訪問的過程當中，還會不斷從新渲染。從新渲染會重複上圖中的第四步(迴流)+第五步(重繪)或者只有第五個步(重繪)。

重繪:當render tree中的一些元素須要更新屬性，而這些屬性只是影響元素的外觀、風格，而不會影響佈局的，好比background-color。
迴流:當render tree中的一部分(或所有)由於元素的規模尺寸、佈局、隱藏等改變而須要從新構建

迴流一定會發生重繪，重繪不必定會引起迴流。重繪和迴流會在咱們設置節點樣式時頻繁出現，同時也會很大程度上影響性能。迴流所需的成本比重繪高的多，改變父節點裏的子節點極可能會致使父節點的一系列迴流。

1）常見引發迴流屬性和方法

任何會改變元素幾何信息(元素的位置和尺寸大小)的操做，都會觸發迴流，

添加或者刪除可見的DOM元素；
元素尺寸改變——邊距、填充、邊框、寬度和高度
內容變化，好比用戶在input框中輸入文字
瀏覽器窗口尺寸改變——resize事件發生時
計算 offsetWidth 和 offsetHeight 屬性
設置 style 屬性的值

2）常見引發重繪屬性和方法

下面例子中，觸發了幾回迴流和重繪？

var s = document.body.style;
s.padding = "2px"; // 迴流+重繪
s.border = "1px solid red"; // 再一次 迴流+重繪
s.color = "blue"; // 再一次重繪
s.backgroundColor = "#ccc"; // 再一次 重繪
s.fontSize = "14px"; // 再一次 迴流+重繪
// 添加node，再一次 迴流+重繪
document.body.appendChild(document.createTextNode('abc!'));

3）如何減小回流、重繪

使用 transform 替代 top
使用 visibility 替換 display: none ，由於前者只會引發重繪，後者會引起迴流（改變了佈局）
不要把節點的屬性值放在一個循環裏當成循環裏的變量。

for(let i = 0; i < 1000; i++) {
    // 獲取 offsetTop 會致使迴流，由於須要去獲取正確的值
    console.log(document.querySelector('.test').style.offsetTop)
}

不要使用 table 佈局，可能很小的一個小改動會形成整個 table 的從新佈局
動畫實現的速度的選擇，動畫速度越快，迴流次數越多，也能夠選擇使用 requestAnimationFrame
CSS 選擇符從右往左匹配查找，避免節點層級過多
將頻繁重繪或者回流的節點設置爲圖層，圖層可以阻止該節點的渲染行爲影響別的節點。好比對於 video 標籤來講，瀏覽器會自動將該節點變爲圖層。

問題三：async和defer的做用是什麼？有什麼區別?

接下來咱們對比下 defer 和 async 屬性的區別：

其中藍色線表明JavaScript加載；紅色線表明JavaScript執行；綠色線表明 HTML 解析。

1）狀況1`<script src="script.js"></script>`

沒有 defer 或 async，瀏覽器會當即加載並執行指定的腳本，也就是說不等待後續載入的文檔元素，讀到就加載並執行。

2）狀況2`<script async src="script.js"></script>` (異步下載)

async 屬性表示異步執行引入的 JavaScript，與 defer 的區別在於，若是已經加載好，就會開始執行——不管此刻是 HTML 解析階段仍是 DOMContentLoaded 觸發以後。須要注意的是，這種方式加載的 JavaScript 依然會阻塞 load 事件。換句話說，async-script 可能在 DOMContentLoaded 觸發以前或以後執行，但必定在 load 觸發以前執行。

3）狀況3 `<script defer src="script.js"></script>`(延遲執行)

defer 屬性表示延遲執行引入的 JavaScript，即這段 JavaScript 加載時 HTML 並未中止解析，這兩個過程是並行的。整個 document 解析完畢且 defer-script 也加載完成以後（這兩件事情的順序無關），會執行全部由 defer-script 加載的 JavaScript 代碼，而後觸發 DOMContentLoaded 事件。

defer 與相比普通 script，有兩點區別：**載入 JavaScript 文件時不阻塞 HTML 的解析，執行階段被放到 HTML 標籤解析完成以後。

在加載多個JS腳本的時候，async是無順序的加載，而defer是有順序的加載。**

問題四：爲何操做 DOM 慢

由於 DOM 是屬於渲染引擎中的東西，而 JS 又是 JS 引擎中的東西。當咱們經過 JS 操做 DOM 的時候，其實這個操做涉及到了兩個線程之間的通訊，那麼勢必會帶來一些性能上的損耗。操做 DOM 次數一多，也就等同於一直在進行線程之間的通訊，而且操做 DOM 可能還會帶來重繪迴流的狀況，因此也就致使了性能上的問題。

問題五：渲染頁面時常見哪些不良現象？

因爲瀏覽器的渲染機制不一樣，在渲染頁面時會出現兩種常見的不良現象----白屏問題和FOUS（無樣式內容閃爍）

FOUC：因爲瀏覽器渲染機制（好比firefox），再CSS加載以前，先呈現了HTML，就會致使展現出無樣式內容，而後樣式忽然呈現的現象；

白屏：有些瀏覽器渲染機制（好比chrome）要先構建DOM樹和CSSOM樹，構建完成後再進行渲染，若是CSS部分放在HTML尾部，因爲CSS未加載完成，瀏覽器遲遲未渲染，從而致使白屏；也多是把js文件放在頭部，腳本會阻塞後面內容的呈現，腳本會阻塞其後組件的下載，出現白屏問題。

總結

瀏覽器工做流程：構建DOM -> 構建CSSOM -> 構建渲染樹 -> 佈局 -> 繪製。
CSSOM會阻塞渲染，只有當CSSOM構建完畢後纔會進入下一個階段構建渲染樹。
一般狀況下DOM和CSSOM是並行構建的，可是當瀏覽器遇到一個script標籤時，DOM構建將暫停，直至腳本完成執行。但因爲JavaScript能夠修改CSSOM，因此須要等CSSOM構建完畢後再執行JS。
若是你想首屏渲染的越快，就越不該該在首屏就加載 JS 文件，建議將 script 標籤放在 body 標籤底部。

參考文章

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，付費客戶有Google、360、金山軟件、百姓網等衆多品牌企業。歡迎你們免費試用！