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

  • 2019 年 11 月 1 日
  • 筆記

前言

「迴流(重排)」和「重繪」基本上算是前端的高頻詞之一,你可以在各個文章及面試題中見到,我們在討論這個詞的時候,其實討論的是瀏覽器的渲染流程。
所以在討論「迴流重繪」之前,我們還需要掌握一些知識;在它之中,我們還需要更深入一點;在這之後,我們還要懂得怎麼去把理論結合到項目實踐中去。

通過這篇文章,你可以學習到的知識:
1、追本溯源,「迴流」和「重繪」這個詞是如何引出的,在了解這兩個詞之前我們還需要了解什麼
2、瀏覽器的渲染流程,「迴流」和「重繪」的原理
3、優化瀏覽器渲染性能,減少「迴流」和「重繪」,動手將這些優化應用到實際開發中

瀏覽器的渲染引擎

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

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

渲染流程

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

WebKit 渲染引擎的主流程:

Mozilla 的 Gecko渲染引擎的主流程:

從圖 3 和圖 4 可以看出,雖然 WebKit 和 Gecko 使用的術語略有不同,但整體的渲染流程是基本相同的,這裡我們參照Webkit引擎來概況一下:

  1. 解析HTML Source,生成DOM樹
  2. 解析CSS,生成CSSOM樹
  3. 將DOM樹和CSSOM樹結合,去除不可見元素,生成渲染樹(Render Tree)
  4. Layout(布局):根據生成的渲染樹,進行布局(Layout),得到節點的幾何資訊(位置,大小)
  5. Painting(重繪):根據渲染樹以及迴流得到的幾何資訊,將 Render Tree 的每個像素渲染到螢幕上

渲染樹與渲染對象

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

生成渲染樹

為了構建渲染樹,瀏覽器主要完成了以下工作:

  1. 從DOM樹的根節點開始遍歷每個可見節點。
  • 某些節點不會被渲染輸出,比如scriptlinkmeta等標籤節點
  • 通過css隱藏的節點會被忽略,比如「display: none」。但是注意,visibility: hidden是會被渲染的(渲染成一個空框),因為它仍佔據布局空間
  1. 對於每個可見的節點,找到CSSOM樹中對應的規則,並應用它們。
  2. 根據每個可見節點以及其對應的樣式,組合生成渲染樹。

渲染對象

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

每一個渲染對象都代表了一個矩形區域,通常對應相關節點的css框,包含寬度、高度和位置等幾何資訊。框的類型受「display」樣式屬性影響,根據不同的 display 屬性,使用不同的渲染對象(如 RenderInlineRenderBlockRenderListItem 等對象)。

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}

我們可以看到,每個渲染對象都有 layoutpaint方法,分別對應了迴流和重繪的方法。

迴流

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

我們還需要通過 Layout 布局階段,來計算它們在設備視口(viewport)內的確切位置和大小,計算這些值的過程稱為迴流布局重排

HTML 採用基於流的布局模型,從根渲染對象(即<html>)開始,遞歸遍歷部分或所有的框架層次結構,為每一個需要計算的渲染對象計算幾何資訊,大多數情況下只要一次遍歷就能計算出幾何資訊。但是也有例外,比如<table>的計算就需要不止一次的遍歷。

全局布局和增量布局

全局布局指觸發了整個render tree範圍的布局,一般是同步觸發的,觸發原因可能包括:

  1. 影響所有渲染元素的全局樣式更改,例如字體大小更改。
  2. 螢幕大小調整。

增量布局是指對標記為「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)和增量兩種。

繪製順序

繪製的順序其實就是元素進入堆棧樣式上下文的順序。這些堆棧會從後往前繪製,因此這樣的順序會影響繪製。塊渲染對象的堆棧順序如下:
1、背景顏色
2、背景圖片
3、邊框
4、子代
5、輪廓

何時觸發迴流和重繪

觸發迴流(reflow):

迴流這一階段主要是計算節點的位置和幾何資訊,那麼當頁面布局和幾何資訊發生變化的時候,就需要迴流.

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

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

以及進行以下流程或操作:

  • 頁面一開始渲染的時候
  • 添加或刪除可見的DOM元素,進行DOM操作等
  • 內容發生變化,比如文本變化或圖片被另一個不同尺寸的圖片所替代
  • 瀏覽器的窗口尺寸變化(因為迴流是根據視口的大小來計算元素的位置和大小的)
  • css偽類激活
  • 進行獲取布局資訊的操作,比如offsetWidthoffsetHeightclientWidthclientHeightwidthheightscrollTopscrollHeight,getComputedStyle, getBoundingClientRect

Note: 具體屬性及操作可以訪問這個網站:What forces layout / reflow

觸發重繪:

重繪是一個元素外觀的改變所觸發的瀏覽器行為,例如改變visibilityoutlinebackground-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';  }

使用 transformopacity 來實現動畫

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

目前可以有合成器單獨處理的屬性有兩個:
transforms 和 opacity

比如我們可以使用translate代替lefttop
使用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的時間要長。

實際開發中,我們要確定可否使用一組開銷更小的樣式,或者替代方式來實現最終結果。

讓複雜的布局「離線」

對於複雜的動畫,或者頻繁觸發迴流的元素,我們
創建一個documentFragmentdiv,在它上面應用所有DOM操作,最後再把它添加到window.document

也可以在一個display:none的元素上進行操作,最終把它顯示出來。因為display:none上的DOM操作不會引發迴流和重繪。

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

其他

避免使用table布局

我們已經在上面說過,<table>的計算需要不止一次的遍歷,table是可以影響之前已經進入的DOM元素的顯示的元素。即使一些小的變化和會導致table中所有其他節點迴流。

參考文獻

瀏覽器的工作原理:新式網路瀏覽器幕後揭秘

Google Developers:渲染樹構建、布局及繪製