摘要： 若干年前，我寫過一篇介紹瀏覽器渲染流水線的文章 - How Rendering Work (in WebKit and Blink)，這篇文章，一來部分內(nèi)容已經(jīng)過時(shí)，二來缺少一個(gè)全局視角來對流水線整體進(jìn)行分析，所以打算重新寫一篇新的文章，從一個(gè)更高抽象層次和高度簡化的方式對瀏覽器的渲染流水線進(jìn)行解析，能讓大部分頁端同學(xué)都能夠看的明白，并以此作為指引來分析和優(yōu)化頁面的渲染／動(dòng)畫性能。

若干年前，我寫過一篇介紹瀏覽器渲染流水線的文章 - How Rendering Work (in WebKit and Blink)，這篇文章，一來部分內(nèi)容已經(jīng)過時(shí)，二來缺少一個(gè)全局視角來對流水線整體進(jìn)行分析，所以打算重新寫一篇新的文章，從一個(gè)更高抽象層次和高度簡化的方式對瀏覽器的渲染流水線進(jìn)行解析，能讓大部分頁端同學(xué)都能夠看的明白，并以此作為指引來分析和優(yōu)化頁面的渲染／動(dòng)畫性能。

有些基本概念如圖層，分塊，光柵化基本沒有發(fā)生變化，如果讀者不理解的話請參考 How Rendering Work (in WebKit and Blink)，本文不再過多解釋。

本文基于當(dāng)前版本的 Chrome 瀏覽器寫成（60 左右），理論上部分知識可以應(yīng)用于其它瀏覽器（當(dāng)然術(shù)語會(huì)有一定差別）或者 Chrome 后續(xù)的版本，但是并不完全保證這一點(diǎn)。

1. 渲染流水線

上圖顯示了 Chrome 一個(gè)高度簡化后的渲染流水線示意圖：

最底層的是 Chrome 最核心的部分 Blink，負(fù)責(zé)JS的解析執(zhí)行，HTML/CSS解析，DOM操作，排版，圖層樹的構(gòu)建和更新等任務(wù)；

Layer Compositor（圖層合成器）接收 Blink 的輸入，負(fù)責(zé)圖層樹的管理，圖層的滾動(dòng)，旋轉(zhuǎn)等矩陣變幻，圖層的分塊，光柵化，紋理上傳等任務(wù)；

Display Compositor 接收 Layer Compositor 的輸入，負(fù)責(zé)輸出最終的 OpenGL 繪制指令，將網(wǎng)頁內(nèi)容通過 GL 貼圖操作繪制到目標(biāo)窗口上，如果忽略掉操作系統(tǒng)本身的窗口合成器，也可以簡單認(rèn)為是繪制在顯示屏上；

當(dāng)我們說 Compositor，在沒有加修飾語的情況下，一般都是指 Layer Compositor。另外術(shù)語 Child Compositor（子合成器）也是指 Layer Compositor，相對于作為 Parent 的 Display Compositor 而言。

1.1 進(jìn)程與線程

一個(gè) Chrome 瀏覽器一般會(huì)有一個(gè) Browser 進(jìn)程，一個(gè) GPU 進(jìn)程，和多個(gè) Renderer 進(jìn)程，通常每個(gè) Renderer 進(jìn)程對應(yīng)一個(gè)頁面。在特殊架構(gòu)（Android WebView）或者特定配置下，Browser 進(jìn)程可以兼作 GPU 進(jìn)程或者 Renderer 進(jìn)程（意味著沒有獨(dú)立的 GPU 或者 Renderer 進(jìn)程），但是 Browser 跟 Renderer，Browser 跟 GPU，Renderer 跟 GPU 之間的系統(tǒng)架構(gòu)和通訊方式基本保持不變，線程架構(gòu)也是同樣。

Blink 主要運(yùn)行在 Renderer 進(jìn)程的 Renderer 線程，我們通常會(huì)稱之為內(nèi)核主線程；

Layer Compositor 主要運(yùn)行在 Renderer 進(jìn)程的 Compositor 線程；

Display Compositor 主要運(yùn)行在 Browser 進(jìn)程的 UI 線程；

Display Compositor 未來應(yīng)該會(huì)移到 GPU 進(jìn)程的主 GPU 線程，當(dāng)然對父子合成器進(jìn)行調(diào)度的部分仍然是在 Browser 進(jìn)程的 UI 線程。

1.2 幀

所有的渲染流水線都會(huì)有幀的概念，幀這個(gè)概念抽象描述了渲染流水線下級模塊往上級模塊輸出的繪制內(nèi)容相關(guān)數(shù)據(jù)的封裝。我們可以看到 Blink 輸出 Main Frame 給 Layer Compositor，Layer Compositor 輸出 Compositor Frame 給 Display Compositor，Display Compositor 輸出 GL Frame 給 Window。我們覺得一個(gè)動(dòng)畫是否流暢，最終取決于 GL Frame 的幀率（也就是目標(biāo)窗口的繪制更新頻率），而覺得一個(gè)觸屏操作是否響應(yīng)即時(shí)，取決于從 Blink 處理事件到 Window 更新的整個(gè)過程的耗時(shí)（理論上應(yīng)該還要加上事件從 Browser 發(fā)送給 Compositor，再發(fā)送給 Blink 的這個(gè)過程的耗時(shí)）。

1.1.1 Main Frame

Main Frame 包含了對網(wǎng)頁內(nèi)容的描述，主要以繪圖指令的形式，或者可以簡單理解為某個(gè)時(shí)間點(diǎn)對整個(gè)網(wǎng)頁的一個(gè)矢量圖快照（可以局部更新）。當(dāng)前版本的 Chrome，圖層化的決策仍然由 Blink 來負(fù)責(zé)，Blink 需要決定如何根據(jù)網(wǎng)頁的 DOM 樹來生成一顆圖層樹，并以 DisplayList 的形式記錄每個(gè)圖層的內(nèi)容（未來圖層化決策應(yīng)該會(huì)轉(zhuǎn)移到 Layer Compositor，Blink 只輸出 DisplayList 樹和 DisplayList 節(jié)點(diǎn)的關(guān)鍵屬性，同時(shí) DisplayList 不再以圖層作為單位，而是以每個(gè)排版對象作為單位）。

圖層化決策一般由以下幾個(gè)因素決定：

特殊元素如 Plugin，Video，Canvas（WebGL）；

維護(hù)正確的層級關(guān)系來保證繪制順序是正確的，比如 Overlap 的計(jì)算；

減少圖層樹的結(jié)構(gòu)變更，減少圖層內(nèi)容的變更（目前 Blink 網(wǎng)頁內(nèi)容的變更是以圖層為原子單位的，如果以一個(gè)元素為根節(jié)點(diǎn)生成圖層，該元素的某些 CSS 屬性如 Transform 的變更不會(huì)引起所屬圖層內(nèi)容的變更）；

第三點(diǎn)是可以被頁端所直接控制來優(yōu)化圖層結(jié)構(gòu)及 Main Frame 性能，像傳統(tǒng)的 translate3d hack 和新的 CSS 屬性 will-change。

1.2.2 Compositor Frame

Layer Compositor 接收 Blink 生成的 Main Frame，并轉(zhuǎn)換成合成器內(nèi)部的圖層樹結(jié)構(gòu)（因?yàn)閳D層化決策仍然由 Blink 負(fù)責(zé)，所以這里的轉(zhuǎn)換基本上可以認(rèn)為是生成一棵同樣的樹，再對逐個(gè)圖層的進(jìn)行拷貝）。

Layer Compositor 需要為每個(gè)圖層進(jìn)行分塊，為每個(gè)分塊分配 Resource（Texture 的封裝），然后安排光柵化任務(wù)。

當(dāng) Layer Compositor 接收到來自 Browser 的繪制請求時(shí)，它會(huì)為當(dāng)前可見區(qū)域的每個(gè)圖層的每個(gè)分塊生成一個(gè) Draw Quad 的繪制指令（矩形繪制，指令實(shí)際上指定了坐標(biāo)，大小，變換矩陣等屬性），所有的 Draw Quad 指令和對應(yīng)的 Resource 的集合就構(gòu)成了 Compositor Frame。Compositor Frame 被發(fā)送往 Browser，并最終到達(dá) Display Compositor（未來也可以直接發(fā)給 Display Compositor）。

1.2.3 GL Frame

Display Compositor 將 Compositor Frame 的每個(gè) Draw Quad 繪制指令轉(zhuǎn)換一個(gè) GL 多邊形繪圖指令，使用對應(yīng) Resource 封裝的 Texture 對目標(biāo)窗口進(jìn)行貼圖，這些 GL 繪圖指令的集合就構(gòu)成了一個(gè) GL Frame，最終由 GPU 執(zhí)行這些 GL 指令完成網(wǎng)頁在窗口上占據(jù)的可見區(qū)域的繪制。

1.3 調(diào)度

Chrome 渲染流水線的調(diào)度是基于請求和狀態(tài)機(jī)響應(yīng)，調(diào)度的最上級中樞運(yùn)行在 Browser UI 線程，它按顯示器的 VSync（垂直同步）周期向 Layer Compositor 發(fā)出輸出下一幀的請求，而 Layer Compositor 根據(jù)自身狀態(tài)機(jī)的狀態(tài)決定是否需要 Blink 輸出下一幀。

Display Compositor 則比較簡單，它持有一個(gè) Compositor Frame 的隊(duì)列不斷的進(jìn)行取出和繪制，輸出的頻率唯二地取決于 Compositor Frame 的輸入頻率和自身繪制 GL Frame 的耗時(shí)。基本上可以認(rèn)為 Layer Compositor 和 Display Compositor 是生產(chǎn)者和消費(fèi)者的關(guān)系。

2. 網(wǎng)頁動(dòng)畫

動(dòng)畫可以看做是一個(gè)連續(xù)的幀序列的組合。我們把網(wǎng)頁的動(dòng)畫分成兩大類 —— 一類是合成器動(dòng)畫，一類是非合成器動(dòng)畫（UC 內(nèi)部也將其稱為內(nèi)核動(dòng)畫，雖然這不是 Chrome 官方的術(shù)語）。

合成器動(dòng)畫顧名思義，動(dòng)畫的每一幀都是由 Layer Compositor 生成并輸出的，合成器自身驅(qū)動(dòng)著整個(gè)動(dòng)畫的運(yùn)行，在動(dòng)畫的過程中，不需要新的 Main Frame 輸入；

內(nèi)核動(dòng)畫，每一幀都是由 Blink 生成，都需要產(chǎn)生一個(gè)新的 Main Frame；

2.1 合成器動(dòng)畫

合成器動(dòng)畫又可以分為兩類：

合成器本身觸發(fā)并運(yùn)行的，比如最常見的網(wǎng)頁慣性滾動(dòng)，包括整個(gè)網(wǎng)頁或者某個(gè)頁內(nèi)可滾動(dòng)元素的滾動(dòng)；

Blink 觸發(fā)然后交由合成器運(yùn)行，比如說傳統(tǒng)的 CSS Translation 或者新的 Animation API，如果它們觸發(fā)的動(dòng)畫經(jīng)由 Blink 判斷可以交由合成器運(yùn)行；

Blink 觸發(fā)的動(dòng)畫，如果是 Transform 和 Opacity 屬性的動(dòng)畫基本上都可以由合成器運(yùn)行，因?yàn)樗鼈儧]有改變圖層的內(nèi)容。不過即使可以交由合成器運(yùn)行，它們也需要產(chǎn)生一個(gè)新的 Main Frame 提交給合成器來觸發(fā)這個(gè)動(dòng)畫，如果這個(gè) Main Frame 包含了大量的圖層變更，也會(huì)導(dǎo)致觸發(fā)的瞬間卡頓，頁端事先對圖層結(jié)構(gòu)進(jìn)行優(yōu)化可以避免這個(gè)問題。

2.2 非合成器動(dòng)畫

非合成器動(dòng)畫也可以分為兩類：

使用 CSS Translation 或者 Animation API 創(chuàng)建的動(dòng)畫，但是無法由合成器運(yùn)行；

使用 Timer 或者 RAF 由 JS 驅(qū)動(dòng)的動(dòng)畫，比較典型的就是 Canvas/WebGL 游戲，這種動(dòng)畫實(shí)際上是由頁端自己定義的，瀏覽器本身并沒有對應(yīng)的動(dòng)畫的概念，也就是說瀏覽器本身是不知道這個(gè)動(dòng)畫什么時(shí)候開始，是否正在運(yùn)行，什么時(shí)候結(jié)束，這些完全是頁端自己的內(nèi)部邏輯；

合成器動(dòng)畫和非合成器動(dòng)畫在渲染流水線上有較大的差異，后者更復(fù)雜，流水線更長。上面四種動(dòng)畫的分類，按渲染流水線的復(fù)雜程度和理論性能排列（復(fù)雜程度由低到高，理論性能由高到低）：

合成器本身觸發(fā)并運(yùn)行的動(dòng)畫；

Blink 觸發(fā)，合成器運(yùn)行的動(dòng)畫；

Blink 觸發(fā)，無法由合成器運(yùn)行的動(dòng)畫；

由 Timer/RAF 驅(qū)動(dòng)的 JS 動(dòng)畫；

長久以來，瀏覽器渲染流水線的設(shè)計(jì)都主要是為了合成器動(dòng)畫的性能而優(yōu)化，甚至在某種程度上導(dǎo)致內(nèi)核動(dòng)畫性能的下降，比如說合成器的異步光柵化機(jī)制。不過這兩年，隨著對 WebApp 渲染性能包括 WebGL 性能的重視，并且隨著主流移動(dòng)設(shè)備的硬件性能持續(xù)提升，合成器動(dòng)畫的性能也已經(jīng)基本不成問題，Chrome 的渲染流水線已經(jīng)更多地針對內(nèi)核動(dòng)畫的性能進(jìn)行優(yōu)化，甚至?xí)?dǎo)致在某些特定狀況下合成器動(dòng)畫性能的下降，比方說傾向于為了維持圖層樹的穩(wěn)定性，減少變更，而生成更多的圖層。不過總的說來，目前 Chrome 的渲染流水線，在主流的移動(dòng)設(shè)備上，大部分場景下，兩者性能都能獲得一個(gè)較好的平衡。

3. 動(dòng)畫性能分析基礎(chǔ)

這里的性能分析主要是針對移動(dòng)設(shè)備，以桌面處理器的性能，大部分場景下都不存在性能問題。目前移動(dòng)設(shè)備的屏幕刷新率基本上都是 60hz，而瀏覽器跟其它應(yīng)用一樣，需要跟屏幕刷新保持垂直同步，也就是動(dòng)畫幀率的上限是 60 幀，這也是我們能夠達(dá)到的最理想的結(jié)果。不過考慮瀏覽器本身的復(fù)雜程度，可能有很多后臺(tái)任務(wù)在運(yùn)行，而且操作系統(tǒng)本身也可能同時(shí)運(yùn)行其它后臺(tái)任務(wù)，并且移動(dòng)平臺(tái)要考慮能耗和散熱，CPU/GPU 的調(diào)度策略會(huì)頻繁地發(fā)生變化，要完全鎖定 60 幀是非常困難的。

如果上限超過 60 幀，實(shí)際平均幀率超過 60 反而不難，但是如果上限是 60 幀，垂直同步下要鎖定 60 幀是非常困難的，要求每一幀的各個(gè)環(huán)節(jié)耗時(shí)都要保持非常穩(wěn)定。

一般而言：

幀率在 55 ～ 60 之間已經(jīng)可以認(rèn)為是非常優(yōu)秀的水平，這時(shí)用戶幾乎感覺不到卡頓；

幀率在 50 ～ 55 之間可以認(rèn)為是良好的水平，用戶感覺到輕微卡頓，但整體來說還是比較流暢；

要達(dá)到 50 幀以上的水平，我們就需要對動(dòng)畫在渲染流水線的每個(gè)重要環(huán)節(jié)進(jìn)行性能計(jì)算，需要知道這些環(huán)節(jié)最長允許的耗時(shí)上限和網(wǎng)頁影響這些環(huán)節(jié)耗時(shí)的主要原因，雖然實(shí)際上很難完全鎖定 60 幀，但是一般來說性能分析/優(yōu)化還是會(huì)以 60 幀為目標(biāo)來倒推各個(gè)環(huán)節(jié)的最大耗時(shí)。

如果是場景比較復(fù)雜的 Canvas/WebGL 游戲，以 30 幀為目標(biāo)幀率是一個(gè)合理的訴求。

3.1 光柵化機(jī)制

在對動(dòng)畫性能進(jìn)行分析之前，需要先說明一下目前的 Chrome 的光柵化機(jī)制。合成器會(huì)監(jiān)控是否需要安排新的光柵化任務(wù)，當(dāng)需要光柵化調(diào)度時(shí)：

合成器找到所有在當(dāng)前可見區(qū)域的圖層；

合成器找到這些圖層在當(dāng)前可見區(qū)域的分塊；

合成器檢查這些分塊是否需要光柵化，如果需要，生成一個(gè)對應(yīng)的光柵化任務(wù)并分配所需要的 Resource 放入任務(wù)隊(duì)列里面；

Renderer 進(jìn)程會(huì)預(yù)先創(chuàng)建一個(gè)或者多個(gè) Worker 線程（移動(dòng)平臺(tái)一般是兩個(gè)），這些線程會(huì)從任務(wù)隊(duì)列里面順序取出每一個(gè)光柵化任務(wù)并運(yùn)行；

光柵化任務(wù)運(yùn)行后，會(huì)通知合成器，合成器根據(jù)需要檢查哪些任務(wù)已經(jīng)完成，已經(jīng)完成的任務(wù)， Resource 會(huì)轉(zhuǎn)交給對應(yīng)的分塊；

實(shí)際的光柵化區(qū)域會(huì)比當(dāng)前可見區(qū)域要更大一些，一般是增加一個(gè)分塊大小單位，對不可見區(qū)域的預(yù)光柵化有助于提升合成器動(dòng)畫的性能和減少出現(xiàn)空白的幾率。

從上可知，合成器的光柵化調(diào)度完全是異步的，合成器在 Compositor 線程需要執(zhí)行的就是安排光柵化任務(wù)和檢查哪些任務(wù)已經(jīng)完成，Compositor 線程本身不會(huì)被真正運(yùn)行光柵化任務(wù)的 Worker 線程所阻塞。

4 合成器動(dòng)畫性能分析和優(yōu)化指南

4.1 動(dòng)畫流水線

上圖顯示了合成器動(dòng)畫的渲染流水線示意圖，根據(jù) Android WebView 平臺(tái)的實(shí)現(xiàn)進(jìn)行繪制，其它平臺(tái)可能略微不同，但對后面的性能分析，在大部分情況下影響不大

整個(gè)流水線的大概過程是：

位于 Browser 進(jìn)程 UI 線程的窗口管理器接收到來自操作系統(tǒng)的屏幕刷新垂直同步信號（VSync），開始準(zhǔn)備輸出新的一幀，它首先給位于 Renderer 進(jìn)程 Compositor 線程的 Layer Compositor 發(fā)送一個(gè) Begin Frame 消息；

Layer Compositor 接收到 Begin Frame 消息后，更新合成器內(nèi)部的狀態(tài)機(jī)，開始準(zhǔn)備輸出 Compositor Frame，在這個(gè)過程中的一個(gè)重要?jiǎng)幼骶褪?Animate，合成器會(huì)檢查當(dāng)前是否有正在運(yùn)行的動(dòng)畫，然后運(yùn)行這些動(dòng)畫，并根據(jù)動(dòng)畫運(yùn)行的結(jié)果改變關(guān)聯(lián)圖層的對應(yīng)屬性（比如慣性滾動(dòng)動(dòng)畫改變圖層的 Scroll Offset，Transform 動(dòng)畫改變圖層的 Transform），Animate 的結(jié)果會(huì)發(fā)送回給 UI 線程告訴其是否有動(dòng)畫正在運(yùn)行，需要更新窗口；

如果 UI 線程確定合成器需要更新窗口，則會(huì)發(fā)送一個(gè) Draw 消息請求合成器輸出下一幀 Compositor Frame；

合成器按下面的過程產(chǎn)生新的 Compositor Frame 并發(fā)送給 Display Compositor； 4.1 合成器找出在當(dāng)前可見區(qū)域內(nèi)顯示的圖層； 4.2 合成器找出這些圖層在可見區(qū)域內(nèi)的分塊； 4.3 如果該分塊已經(jīng)有分配 Resource（說明此分塊已經(jīng)完成光柵化），則產(chǎn)生一個(gè) Draw Quad 的命令置入 Compositor Frame 中，如果沒有則跳過；

Display Compositor 接受到新的 Compositor Frame 后，對 Compositor Frame 進(jìn)行 Render，將每一個(gè) Draw Quad 命令轉(zhuǎn)換成一個(gè) GL Draw Call，然后 GPU 執(zhí)行所有的 GL 指令完成最后的窗口繪制；

上述流程的一些關(guān)鍵點(diǎn)是：

Draw 的過程中，合成器不會(huì)等待可見的分塊光柵化完成，這讓合成器充分利用了異步光柵化的機(jī)制來提升性能，但是也會(huì)造成動(dòng)畫過程中可能會(huì)出現(xiàn)空白的分塊，比如快速滾動(dòng)頁面有時(shí)會(huì)看到空白區(qū)域；

在合成器動(dòng)畫過程中，Layer Compositor 和 Display Compositor 是異步并發(fā)的，在 Display Compositor 輸出 GL Frame N 的時(shí)候，Layer Compositor 已經(jīng)可以開始輸出下一幀 Compositor Frame N + 1；

4.2 動(dòng)畫耗時(shí)分析

Begin Frame 的耗時(shí)一般很短，大概 1 ～ 2 毫秒左右；

Draw 的耗時(shí)也不長，一般不超過 5 毫秒，耗時(shí)主要取決于網(wǎng)頁的圖層復(fù)雜度，總的來說合成器動(dòng)畫過程中 Compositor 線程的開銷一般都不會(huì)構(gòu)成性能瓶頸；

Render 的耗時(shí)也不長，一般也是不超過 5 毫秒，耗時(shí)主要取決于當(dāng)前可見區(qū)域內(nèi)的可見分塊的數(shù)量；

GPU 部分的耗時(shí)比較長，耗時(shí)主要取決于當(dāng)前可見區(qū)域內(nèi)的可見分塊的總面積，也就是繪制的總面積，一旦 Render + GPU 部分的耗時(shí)大于 16.7 毫秒，動(dòng)畫就會(huì)出現(xiàn)掉幀；

總的來說影響合成器動(dòng)畫性能的最關(guān)鍵因素就是過度繪制系數(shù)（Overdraw，可以理解為繪制的面積和可見區(qū)域面積的比例），如果網(wǎng)頁本身存在大量圖層堆疊情況，導(dǎo)致過度繪制系數(shù)過高，就會(huì)嚴(yán)重影響合成器動(dòng)畫的性能。經(jīng)驗(yàn)顯示，過度繪制系數(shù)比較理想的值是在 2 以內(nèi)，一般建議不超過 3，這樣可以保證在中低端的移動(dòng)設(shè)備上也有不錯(cuò)的性能表現(xiàn)。

另外，合成器動(dòng)畫過程中，Compositor 和 GPU 線程是前臺(tái)線程，它們雖然理論上不會(huì)被 Worker 和 Renderer 線程阻塞，但是在真實(shí)的運(yùn)行場景中，移動(dòng)設(shè)備的 CPU/GPU 和內(nèi)存帶寬等硬件資源是有限的，如果 Worker 和 Renderer 線程處于高負(fù)荷狀態(tài)下，也會(huì)導(dǎo)致前臺(tái)的 Compositor 和 GPU 線程阻塞，最終導(dǎo)致合成器動(dòng)畫掉幀。

這種現(xiàn)象常見于：

網(wǎng)頁在合成器動(dòng)畫比如慣性滾動(dòng)過程中，有大量的 JS 加載圖片或者其它內(nèi)容，并頻繁地對 DOM 樹進(jìn)行操作；

網(wǎng)頁的圖層樹非常復(fù)雜，并且其結(jié)構(gòu)在合成器動(dòng)畫過程中頻繁發(fā)生變化，導(dǎo)致大量的光柵化任務(wù)在 Worker 線程運(yùn)行；

4.3 動(dòng)畫性能優(yōu)化 Checklist

根據(jù)上述的耗時(shí)分析，我們可以給出一個(gè)頁端優(yōu)化合成器動(dòng)畫性能的簡單 Checklist：

檢查網(wǎng)頁的圖層結(jié)構(gòu)是否合理，包括深度和數(shù)量，一般來說深度在 10 以內(nèi)，數(shù)量在 100 以內(nèi)是比較合理的值；

檢查網(wǎng)頁的合成器動(dòng)畫，包括網(wǎng)頁的慣性滾動(dòng)，各種圖層的淡入/淡出等動(dòng)畫，在動(dòng)畫過程中，是否同時(shí)存在大量的網(wǎng)絡(luò)加載和 DOM 操作，網(wǎng)頁圖層結(jié)構(gòu)是否保持穩(wěn)定；

當(dāng)網(wǎng)頁處于任一滾動(dòng)位置上時(shí)，它的當(dāng)前過度繪制系數(shù)是否合理；

如何判斷網(wǎng)頁的圖層結(jié)構(gòu)是否穩(wěn)定，一般而言，如果是位于葉子節(jié)點(diǎn)的圖層增加或者移除，對整個(gè)圖層結(jié)構(gòu)影響并不大，但是如果是中間節(jié)點(diǎn)的圖層增加或者移除，對圖層結(jié)構(gòu)的影響就比較大了，并且越是接近根節(jié)點(diǎn)，影響就越大。

現(xiàn)在的頁端都會(huì)大量使用異步加載來優(yōu)化加載性能和流量，但是容易出現(xiàn)導(dǎo)致動(dòng)畫掉幀的現(xiàn)象。要平衡好這一點(diǎn)意味著需要實(shí)現(xiàn)一個(gè)加載和關(guān)聯(lián) DOM 操作的調(diào)度器，如果檢查到動(dòng)畫正在運(yùn)行，則停止加載或者通過節(jié)流閥機(jī)制降低加載的并發(fā)數(shù)量和頻率，同時(shí)可以通過事先生成相應(yīng)的 DOM 節(jié)點(diǎn)和圖層作為占位符來避免加載后的圖層結(jié)構(gòu)發(fā)生劇烈變化。

5 非合成器動(dòng)畫性能分析和優(yōu)化指南

前面已經(jīng)我們已經(jīng)把非合成器動(dòng)畫區(qū)分為 Blink 觸發(fā)，無法由合成器運(yùn)行的動(dòng)畫和由 Timer/RAF 驅(qū)動(dòng)的 JS 動(dòng)畫兩類，因?yàn)榍罢呖梢哉J(rèn)為是后者的一個(gè)簡化版本，所以這一章主要討論 Timer/RAF 驅(qū)動(dòng)的 JS 動(dòng)畫。

5.1 動(dòng)畫流水線

從上圖可以看出非合成器動(dòng)畫的流水線比合成器動(dòng)畫更長更復(fù)雜，并且非合成器動(dòng)畫的后半段跟合成器動(dòng)畫是一致的。

JavaScipt 部分是頁端實(shí)現(xiàn)的邏輯，可能包含了計(jì)算的部分，和調(diào)用瀏覽器提供的 API 的部分（修改 DOM 樹，CSS 屬性等），最終改變了網(wǎng)頁的內(nèi)容；

網(wǎng)頁內(nèi)容被改變會(huì)導(dǎo)致 Blink 生成新的 MainFrame，MainFrame 包括了重排版，更新圖層樹，和重新記錄發(fā)生變更的圖層的內(nèi)容，生成新的 DisplayList，等等；

Blink 生成新的 MainFrame 后需要向合成器發(fā)起 Commit 的請求，合成器在 Commit 過程中根據(jù) MainFrame 生成自身的圖層樹，Blink 在 Commit 的過程中保持阻塞狀態(tài)，Commit 完成后再繼續(xù)運(yùn)行；

合成器實(shí)際上有兩棵圖層樹，新提交的 MainFrame 生成的是 Pending 樹，用于繪制 Draw 的是 Active 樹，只有當(dāng) Pending 樹當(dāng)前可見區(qū)域部分的分塊全部完成 Rasterize 后，才會(huì)進(jìn)入 Active 步驟，在 Active 的過程中，Pending 樹相對于 Active 樹的變更部分才會(huì)被同步到 Active 樹；

Active 后，合成器會(huì)向 UI 線程的窗口管理器發(fā)起重繪請求，窗口管理器會(huì)在下一個(gè) VSync 的時(shí)候開始繪制新的一幀，后面的流程就跟合成器動(dòng)畫是一樣的了；

上述流程的一些關(guān)鍵點(diǎn)是：

在合成器動(dòng)畫中，分塊沒有完成光柵化，出現(xiàn)空白是被允許的，這樣瀏覽器可以更好地保證合成器動(dòng)畫的幀率，但是在非合成器動(dòng)畫中出現(xiàn)空白是不被允許的，因?yàn)樾碌?MainFrame 常常會(huì)帶來大面積的變更，如果允許空白的話可能會(huì)出現(xiàn)非常不好的視覺效果。這樣就導(dǎo)致合成器需要使用兩棵圖層樹來構(gòu)建一個(gè)類似雙緩沖的機(jī)制，只有當(dāng) Pending 樹在后臺(tái)完成可見區(qū)域的光柵化時(shí)才被允許同步到 Active 樹；

在非合成器動(dòng)畫過程中，Main Frame N，Main Frame N Active；Compositor Frame N，GL Frame N 這四個(gè) Block 基本上可以認(rèn)為是可以并發(fā)運(yùn)行的（唯一會(huì)阻塞的環(huán)節(jié)是 Commit，不過 Commit 耗時(shí)一般不長），理論上我們要實(shí)現(xiàn) 60 幀的非合成器動(dòng)畫，只需要保證其中每個(gè) Block 的耗時(shí)總和小于 16.7 毫秒即可。當(dāng)然實(shí)際的狀況下，在移動(dòng)設(shè)備上很難實(shí)現(xiàn)這么多線程完全并發(fā)運(yùn)行，加上過多線程帶來的互相通訊的開銷，使得每個(gè) Block 的最大允許耗時(shí)實(shí)際上是小于 16.7 毫秒的；

5.2 動(dòng)畫耗時(shí)分析和優(yōu)化指南

JavaScipt 的耗時(shí)是由頁端自己的邏輯決定的，一般超過 10 毫秒就基本上很難實(shí)現(xiàn) 60 幀的非合成器動(dòng)畫了；

MainFrame 的耗時(shí)主要取決于網(wǎng)頁 DOM 樹，圖層樹的復(fù)雜程度和變化程度，在變更很小，比如只有幾個(gè)元素的內(nèi)容發(fā)生變化，圖層樹不變的情況下，一般耗時(shí)都是在 3 ～ 5 毫秒左右，如果變更很大，幾十甚至幾百都是有可能的；

Commit 的耗時(shí)主要取決于圖層樹的復(fù)雜程度，一般耗時(shí)都很短，大概 2 ~ 3 毫秒上下；

Rasterize 的耗時(shí)范圍變化極大，取決于網(wǎng)頁內(nèi)容的復(fù)雜程度和新 MainFrame 在當(dāng)前可見區(qū)域內(nèi)網(wǎng)頁內(nèi)容發(fā)生變化的總面積，另外圖片解碼也發(fā)生在這個(gè)階段，而圖片解碼也是光柵化耗時(shí)最多的一個(gè)環(huán)節(jié)，光柵化的耗時(shí)從幾毫秒到幾百毫秒都有可能（圖片在第一次被光柵化時(shí)被解碼，一直在可見區(qū)域內(nèi)的圖片不會(huì)被反復(fù)重解碼）；

Active 跟 Commit 的耗時(shí)類似，主要取決于圖層樹的復(fù)雜程度，一般耗時(shí)很短，大概 2 ~ 3 毫秒上下；

總的來說對非合成器動(dòng)畫性能影響最大的通常是 JavaScript 和 Rasterize，要實(shí)現(xiàn)高性能的非合成器動(dòng)畫，頁端需要很小心地控制 JavaScript 部分的耗時(shí)，并避免在每一幀中引入大面積的網(wǎng)頁內(nèi)容變化和大幅度的圖層結(jié)構(gòu)變化。另外非合成器動(dòng)畫的后半段就是合成器動(dòng)畫，所以對合成器動(dòng)畫的性能優(yōu)化要求也同樣適應(yīng)于非合成器動(dòng)畫。

另外對于 WebGL 來說，當(dāng)在 JavaScript 里面調(diào)用 WebGL API 時(shí)，這些命令只是被 Chrome 緩存起來，并不會(huì)在 Renderer 線程調(diào)用真正的 GL API，所以 WebGL API 在 JavaScript 部分的耗時(shí)只是一個(gè) JS Binding 調(diào)用的 Overhead，最終繪制 WebGL 內(nèi)容的 GPU 耗時(shí)實(shí)際上是被包含在最后的 GPU 的步驟里面。但是在移動(dòng)平臺(tái)上一個(gè) JS Binding 調(diào)用的 Overhead 是相當(dāng)高的，大概在 0.01 毫秒這個(gè)范圍，所以每一幀超過 1000 個(gè) WebGL API 調(diào)用的 WebGL 游戲，性能阻塞的瓶頸有很大概率會(huì)出現(xiàn)在 JavaScript 也就是 CPU 上，而不是 GPU。

文章作者：小扎zack

原文鏈接：瀏覽器渲染流水線解析

總結(jié)

以上是生活随笔為你收集整理的浏览器渲染流水线解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。