從瀏覽器渲染原理，淺談迴流重繪與效能優化
目錄
- 前言
- 瀏覽器的渲染引擎
- 渲染流程
- 渲染樹與渲染物件
- 迴流
- 全域性佈局和增量佈局
- "迴流"還是"重排"？
- 重繪
- 何時觸發迴流和重繪
- 渲染效能優化
- 合併多次佈局操作
- 減少或避免強制同步佈局
- 使用
transform和opacity來實現動畫 - 簡化繪製的複雜度、減小繪製區域
- 讓複雜的佈局“離線”
- 其他
- 參考文獻
前言
“迴流（重排）”和“重繪”基本上算是前端的高頻詞之一，你可以在各個文章及面試題中見到，我們在討論這個詞的時候，其實討論的是瀏覽器的渲染流程。
所以在討論“迴流重繪”之前，我們還需要掌握一些知識；在它之中，我們還需要更深入一點；在這之後，我們還要懂得怎麼去把理論結合到專案實踐中去。
通過這篇文章，你可以學習到的知識：
1、追本溯源，“迴流”和“重繪”這個詞是如何引出的，在瞭解這兩個詞之前我們還需要了解什麼
2、瀏覽器的渲染流程，“迴流”和“重繪”的原理
3、優化瀏覽器渲染效能，減少“迴流”和“重繪”，動手將這些優化應用到實際開發中
瀏覽器的渲染引擎
瀏覽器的主要元件有：使用者介面、瀏覽器引擎、渲染引擎、網路、使用者介面後端、JavaScript直譯器、資料儲存。
瀏覽器的主要功能就是向伺服器發出請求，在瀏覽器視窗中展示您選擇的網路資源。瀏覽器在解析HTML文件，將網頁內容展示到瀏覽器上的流程，其實就是渲染引擎完成的。
渲染流程
我們在這裡討論Gecko和Webkit這兩種渲染引擎，其中Firefox 使用的是 Gecko，這是 Mozilla 公司“自制”的呈現引擎。而 Safari 和 Chrome 瀏覽器使用的都是 WebKit。
WebKit 渲染引擎的主流程：
Mozilla 的 Gecko渲染引擎的主流程：
從圖 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）和增量兩種。
繪製順序
繪製的順序其實就是元素進入堆疊樣式上下文的順序。這些堆疊會從後往前繪製，因此這樣的順序會影響繪製。塊渲染物件的堆疊順序如下：
1、背景顏色
2、背景圖片
3、邊框
4、子代
5、輪廓
何時觸發迴流和重繪
觸發迴流(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：渲染樹構建、佈局及繪製