從瀏覽器渲染原理，淺談迴流重繪與性能優化

時間 2019-11-09

原文原文鏈接

目錄css

前言

「迴流（重排）」和「重繪」基本上算是前端的高頻詞之一，你能夠在各個文章及面試題中見到，咱們在討論這個詞的時候，其實討論的是瀏覽器的渲染流程。
因此在討論「迴流重繪」以前，咱們還須要掌握一些知識；在它之中，咱們還須要更深刻一點；在這以後，咱們還要懂得怎麼去把理論結合到項目實踐中去。html

經過這篇文章，你能夠學習到的知識：
一、追本溯源，「迴流」和「重繪」這個詞是如何引出的，在瞭解這兩個詞以前咱們還須要瞭解什麼
二、瀏覽器的渲染流程，「迴流」和「重繪」的原理
三、優化瀏覽器渲染性能，減小「迴流」和「重繪」，動手將這些優化應用到實際開發中前端

瀏覽器的渲染引擎

瀏覽器的主要組件有：用戶界面、瀏覽器引擎、渲染引擎、網絡、用戶界面後端、JavaScript解釋器、數據存儲。html5

瀏覽器的主要功能就是向服務器發出請求，在瀏覽器窗口中展現您選擇的網絡資源。瀏覽器在解析HTML文檔，將網頁內容展現到瀏覽器上的流程，其實就是渲染引擎完成的。node

渲染流程

咱們在這裏討論Gecko和Webkit這兩種渲染引擎，其中Firefox 使用的是 Gecko，這是 Mozilla 公司「自制」的呈現引擎。而 Safari 和 Chrome 瀏覽器使用的都是 WebKit。git

WebKit 渲染引擎的主流程：
github

Mozilla 的 Gecko渲染引擎的主流程：
web

從圖 3 和圖 4 能夠看出，雖然 WebKit 和 Gecko 使用的術語略有不一樣，但總體的渲染流程是基本相同的，這裏咱們參照Webkit引擎來概況一下：面試

解析HTML Source，生成DOM樹
解析CSS，生成CSSOM樹
將DOM樹和CSSOM樹結合，去除不可見元素，生成渲染樹(Render Tree)
Layout(佈局):根據生成的渲染樹，進行佈局(Layout)，獲得節點的幾何信息（位置，大小）
Painting(重繪):根據渲染樹以及迴流獲得的幾何信息，將 Render Tree 的每一個像素渲染到屏幕上

渲染樹與渲染對象

渲染樹(render tree)是由可視化元素按照其顯示順序而組成的樹，也是文檔的可視化表示。它的做用是讓您按照正確的順序繪製內容。後端

生成渲染樹

爲了構建渲染樹，瀏覽器主要完成了如下工做：

從DOM樹的根節點開始遍歷每一個可見節點。

某些節點不會被渲染輸出，好比script、link、meta等標籤節點
經過css隱藏的節點會被忽略，好比「display: none」。可是注意，visibility: hidden是會被渲染的（渲染成一個空框），由於它仍佔據佈局空間

對於每一個可見的節點，找到CSSOM樹中對應的規則，並應用它們。
根據每一個可見節點以及其對應的樣式，組合生成渲染樹。

渲染對象

Firefox 將渲染樹中的元素稱爲「框架」。WebKit 使用的術語是渲染器(renderer)或渲染對象(render object)。

每個渲染對象都表明了一個矩形區域，一般對應相關節點的css框，包含寬度、高度和位置等幾何信息。框的類型受「display」樣式屬性影響，根據不一樣的 display 屬性，使用不一樣的渲染對象(如 RenderInline、RenderBlock、RenderListItem 等對象)。

WebKits RenderObject 類是全部渲染對象的基類，其定義以下：

class RenderObject{
  virtual void layout();
  virtual void paint(PaintInfo);
  virtual void rect repaintRect();
  Node* node;  //the DOM node
  RenderStyle* style;  // the computed style
  RenderLayer* containgLayer; //the containing z-index layer}

咱們能夠看到，每一個渲染對象都有 layout 和 paint方法，分別對應了迴流和重繪的方法。

迴流

渲染對象在建立完成並添加到渲染樹時，是將DOM節點和它對應的樣式結合起來，並不包含位置和大小信息。

咱們還須要經過 Layout 佈局階段，來計算它們在設備視口(viewport)內的確切位置和大小，計算這些值的過程稱爲迴流、佈局或重排。

HTML 採用基於流的佈局模型，從根渲染對象（即<html>）開始，遞歸遍歷部分或全部的框架層次結構，爲每個須要計算的渲染對象計算幾何信息，大多數狀況下只要一次遍歷就能計算出幾何信息。可是也有例外，好比<table>的計算就須要不止一次的遍歷。

全局佈局和增量佈局

全局佈局指觸發了整個render tree範圍的佈局，通常是同步觸發的，觸發緣由可能包括：

影響全部渲染元素的全局樣式更改，例如字體大小更改。
屏幕大小調整。

增量佈局是指對標記爲「dirty」的渲染對象進行佈局。它通常是異步執行的，瀏覽器將增量佈局的「reflow 命令」加入隊列，而調度程序會觸發這些命令的批量執行。

可是請求樣式信息（例如offsetHeight,
getBoundingClientRect等）的腳本可同步觸發增量佈局。

Note: dirty bit
爲避免對全部細小更改都進行總體佈局，瀏覽器採用了一種「dirty bit」的系統。若是某個渲染對象發生了更改，或者將自身及其子代標註爲「dirty」，則須要進行佈局。

"迴流"仍是"重排"？

本質上它們是一樣的流程，只是在不一樣瀏覽器引擎下的「說法」有所差別。

Gecko 將視覺格式化元素組成的樹稱爲 "Frame tree" 框架樹。每一個元素都是一個框架；
對於元素的放置，將其稱爲 "Reflow" 迴流。
WebKit 使用的術語是 "Render Tree" 渲染樹，它由"Render Objects"組成。對於元素的放置，WebKit 使用的術語是 "Layout" 佈局（或Relayout重排）

重繪

在計算出節點可見性、它們的計算樣式以及幾何信息後，咱們還須要將渲染樹中的每一個節點，轉換成屏幕上的實際像素。這一步一般稱爲「重繪」。

重繪是填充像素的過程。它涉及繪出文本、顏色、圖像、邊框和陰影，基本上包括元素的每一個可視部分。在重繪階段，系統會遍歷渲染樹，並調用渲染對象的「paint」方法，將渲染對象的內容顯示在屏幕上。

和佈局同樣，重繪也分爲全局（繪製整個render tree）和增量兩種。

繪製順序

繪製的順序其實就是元素進入堆棧樣式上下文的順序。這些堆棧會從後往前繪製，所以這樣的順序會影響繪製。塊渲染對象的堆棧順序以下：
一、背景顏色
二、背景圖片
三、邊框
四、子代
五、輪廓

什麼時候觸發迴流和重繪

觸發迴流(reflow)：

迴流這一階段主要是計算節點的位置和幾何信息，那麼當頁面佈局和幾何信息發生變化的時候，就須要迴流.

改變這些屬性會觸發迴流：

盒模型相關的屬性: width，height，margin，display，border等
定位屬性及浮動相關的屬性: top,position,float等
改變節點內部文字結構也會觸發迴流:text-align, overflow, font-size, line-height, vertival-align等

以及進行如下流程或操做：

頁面一開始渲染的時候
添加或刪除可見的DOM元素，進行DOM操做等
內容發生變化，好比文本變化或圖片被另外一個不一樣尺寸的圖片所替代
瀏覽器的窗口尺寸變化（由於迴流是根據視口的大小來計算元素的位置和大小的）
css僞類激活
進行獲取佈局信息的操做，好比offsetWidth、offsetHeight、clientWidth、clientHeight、width、height、scrollTop、scrollHeight,getComputedStyle, getBoundingClientRect等

Note: 具體屬性及操做能夠訪問這個網站：What forces layout / reflow

觸發重繪：

重繪是一個元素外觀的改變所觸發的瀏覽器行爲，例如改變visibility、outline、background-color等屬性，這些屬性只是影響元素的外觀，風格，而不會影響佈局的。

瀏覽器會根據元素的新屬性從新繪製，使元素呈現新的外觀。重繪不會帶來從新佈局，並不必定伴隨迴流。

Note: 若是想知道更改任何指定 CSS 屬性將觸發迴流仍是重繪，請查看 CSS 觸發器

咱們根據渲染的流程可知，迴流必定會觸發重繪，而重繪不必定會迴流

渲染性能優化

迴流和重繪的代價是比較昂貴的，渲染性能優化，就是要儘量減小Layout迴流和Paint重繪發生的次數，將回流和重繪的影響範圍限制在單獨的圖層以內

合併屢次佈局操做

咱們能夠合併屢次對DOM和樣式的修改，而後一次處理掉，以此來最小化迴流和重繪操做，好比：

// bad
const el = document.getElementById('test');
el.style.margin = '5px';
el.style.width = '100px';
el.style.borderRight = '2px';

例子中，有三個樣式屬性被修改了，每個都會影響元素的幾何結構，引發迴流。（固然，大部分現代瀏覽器都對其作了優化，只會觸發一次。可是若是在舊版的瀏覽器或者在上面代碼執行的時候，有其餘代碼訪問了佈局信息，那麼就會致使三次迴流）

咱們合併全部的佈局操做，而後統一處理，好比這樣：

// good
const el = document.getElementById('test');
el.style.cssText += 'margin: 5px;width: 100px;border-right: 2px; '

減小或避免強制同步佈局

上面咱們提到，訪問一些屬性（就是offsetWidth那一堆屬性）會致使瀏覽器強制清空隊列，進行強制同步佈局。實際使用中能夠儘可能避免，若是不能避免，也應該減小。

好比咱們想批量將一些標籤的寬度設爲某個box的寬度，咱們可能會寫成下面這樣：

// bad
   for (let i = 0; i < elment.length; i++) {
        elment[i].style.width = box.offsetWidth + 'px';
    }

這段代碼看上去問題不大，可是在每次循環的時候，都會去讀取box的offsetWidth，致使瀏覽器每次都會因強制同步佈局而觸發迴流，形成了很大的性能問題。

相似這這狀況，咱們能夠把讀取到的offsetWidth進行緩存：

// good
const width = box.offsetWidth;
for (let i = 0; i < element.length; i++) {
    element[i].style.width = width + 'px';
}

使用 `transform` 和 `opacity` 來實現動畫

最佳的性能渲染流程，就是直接避開回流和重繪，只運行Composite合成這一操做。

目前能夠有合成器單獨處理的屬性有兩個：
transforms 和 opacity

好比咱們可使用translate代替left、top。
使用opacity代替visibility等

簡化繪製的複雜度、減少繪製區域

除 transform 或 opacity 屬性以外，更改任何屬性始終都會觸發繪製。

繪製一般是像素管道中開銷最大的部分；應儘量避免繪製。

經過層的提高來減小繪製區域

繪製並不是老是繪製到內存中的單個圖像。事實上，在必要時瀏覽器能夠繪製到多個圖像或合成器層，各個層能夠在彼此的上面處理併合成，以建立最終圖像。

建立新層的最佳方式是使用 will-change CSS 屬性。
此方法在 Chrome、Opera 和 Firefox 上有效，而且經過 transform 的值將建立一個新的合成器層：

.moving-element { 
    will-change: transform;
}

對於不支持 will-change 但受益於層建立的瀏覽器，例如 Safari 和 Mobile Safari，須要開啓GPU加速來強制建立一個新層：

.moving-element { 
    transform: translateZ(0);
}

優化或減小動畫編排

減小繪製區域每每是編排您的動畫和變換，使其不過多重疊，或設法減小動畫編排，避免對頁面的某些部分設置動畫。

下降繪製的複雜性

一些css屬性的繪製比其餘繪製的開銷更大。例如，繪製任何涉及模糊（例如shadow）的元素所花的時間將比繪製一個border的時間要長。

實際開發中，咱們要肯定能否使用一組開銷更小的樣式，或者替代方式來實現最終結果。

讓複雜的佈局「離線」

對於複雜的動畫，或者頻繁觸發迴流的元素，咱們
建立一個documentFragment或div，在它上面應用全部DOM操做，最後再把它添加到window.document。

也能夠在一個display:none的元素上進行操做，最終把它顯示出來。由於display:none上的DOM操做不會引起迴流和重繪。

也可使用絕對定位，讓它脫離文檔流，從而避免引發父元素以及後續元素的頻繁迴流。

其餘

避免使用table佈局

咱們已經在上面說過，<table>的計算須要不止一次的遍歷，table是能夠影響以前已經進入的DOM元素的顯示的元素。即便一些小的變化和會致使table中全部其餘節點回流。

參考文獻

瀏覽器的工做原理：新式網絡瀏覽器幕後揭祕

Google Developers：渲染樹構建、佈局及繪製

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。