高性能Web動畫和渲染原理系列（5）合成層的生成條件和陷阱

示例代碼托管在：http://www.github.com/dashnowords/blogs

部落格園位址：《大史住在大前端》原創博文目錄

華為雲社群位址：【你要的前端打怪更新指南】

目錄

• 一. 硬體加速相關的幾個概念
• 二. 合成層的生成條件
  • 顯式提升
  • 隐式提升
• 三. 硬體加速的權衡
• 四. 動畫實作的一些建議

之前介紹到了

RenderLayer

渲染層的概念，在涉及到硬體加速的話題時，出現了很多新的概念，參考《Webkit技術内幕》一書的介紹總結如下：

Webkit

決定将哪些

RenderLayer

對象組合在一起，形成一個有後端存儲的新層，這一新層不久後會用于合成，這裡稱之為合成層（

CompositingLayer

）。每一個合成層都會對應一個或多個後端存儲，由

RenderLayerBacking

類進行統一管理，後端存儲空間使用

GraphicsLayer

來表示，也就是說

RenderLayerBacking

管理着一個或多個與對應的合成層有關的

GraphicsLayer

。

筆者旁白：對于渲染過程來說，隻需要了解這裡形成了新的

CompositingLayer

合成層就可以了，其他的層概念基本都是用于實作對

CompositingLayer

功能支援的，概念數量太多對于了解宏觀流程是一大障礙。

合成層的處理是依賴于硬體加速的，但是

GPU

的存儲空間有限最好不要濫用，過多的合成層有可能還會造成相反的效果，是以浏覽器隻會将滿足下列任意條件的

RenderLayer

提升為

CompositingLayer

：

• 具有

  CSS3D

  屬性或

  CSS

  透視效果
• 包含的

  RenderObject

  節點表示的是使用硬體加速的視訊解碼技術的HTML5

  video

  元素

• RenderObject

  節點包含使用了硬體加速的

  Canvas2D

  或

  WebGL

  技術
• 使用了

  CSS

  透明效果或

  CSS

  變形動畫
• 使用了硬體加速的

  CSS Filters

  技術（有的文獻中表示

  filters

  屬性并沒有提升為合成層的效果，推測隻有一部分

  filters

  濾鏡效果需要使用硬體加速，并非所有）
• 使用了剪裁

  Clip

  或者反射

  Reflection

  ，并且它的後代中包含一個合成層
• 擁有一個Z坐标比自己小的兄弟節點，且該節點是一個合成層。

上面的規則裡我們最熟悉的可能就是

transform:translateZ(0)

或者在關鍵幀動畫的定義中改變

transform

和

opacity

屬性。當然，随着技術的演進，上面的規則并不一定全面，

Chromium

官網提供的開發者演講PPT中也對提升的理由進行了相關的描述：

你可以在

Chrome

調試面闆的【Layers】功能中對分層相關的結果進行檢視，檢視哪些層進行了提升以及被提升的具體原因，避免出現與自己意圖相悖的層提升：

RenderLayer

滿足特殊條件時被提升為

CompositingLayer

對開發者而言是比較可控的。但除此之外，在浏覽器的合成階段，還存在隐式合成的狀況，一些特定的場景中出現的合成層并不是開發者主觀期望的。

隐式合成主要發生在元素出現重疊時，層級較低的元素如果被提升為合成層後，最終合成的結果就可能出現在原來比自己層級更高的元素之上，進而出現錯誤的堆疊關系，為了糾正這種關系，隻能讓原本層級高（但是并不用提升為

合成層

的元素）發生提升也成為合成層。例如下面的代碼：

<div style="position:absolute;height:200px;width:200px;background-color: #DA5961;"></div>
<div style="position:absolute;left:30px;top:50px;height:200px;width:200px;background-color: #3498db;"></div>
<div style="position:absolute;left:60px;top:100px;height:200px;width:200px;background-color: #1abc9c;"></div>
           

三個div盒子堆疊在一起，可以看到它們都繪制在同一個層上（這裡的層并不與

RenderLayer

對應，畢竟它隻是一個中間态的樹結構）：

此時如果為最底下的紅色矩形添加

transform:translateZ(0)

屬性将其提升為合成層後，為了保證正确的堆疊關系，藍色和綠色的矩形就會被提升為合成層，代碼如下：

<div style="transform:translateZ(0);position:absolute;height:200px;width:200px;background-color: #DA5961;"></div>
<div style="position:absolute;left:30px;top:50px;height:200px;width:200px;background-color: #3498db;"></div>
<div style="position:absolute;left:60px;top:100px;height:200px;width:200px;background-color: #1abc9c;"></div>
           

藍色和綠色的矩形并沒有形成獨立的合成層，而是被壓縮在同一個合成層中：

從上圖中的細節資訊中可以看到，提升的原因是

layerFotSquashingContent

，也就是為了保證堆疊順序的正确，用一個單獨的合成層來将受到影響的元素收集在一起，既保證堆疊順序，也避免在期望之外生成過多的合成層。如果調整綠色矩形的位置，就可以看到，當視覺上不存在覆寫時，它就不需要提升了：

BUT！！！還沒完，最坑的部分來了，如果此時給藍色的

div

加上一點動畫，你會發現綠色

div

又被提升到了獨立的合成層上，盡管他們之間并沒有重疊區，但還是被提升了：

從圖中的合成原因可以看到：它可能和一個相鄰的合成層元素發生交疊，是以被提升了。沒錯，就是“可能”。Fouber這篇CSS硬體加速也有坑中的示例更加詳細，子元素引發父元素提升，父元素又引發兄弟元素提升。

所有的技術方案都是有代價的，這是亘古不變的道理，合成層的好處很明顯，

GPU

比

CPU

的處理速度快很多，觸發

repaint

重繪時，隻需要重繪獨立的層，然後重新合成即可，不需要重繪整個畫面。但它也存在一些弊端：首先是資料傳輸的問題，

CPU

GPU

的關系就好比用戶端和服務端一樣，它們的協作是需要傳輸資料的，當層的數量達到一定量級後，傳輸的速度就會影響到整體的處理效率，進而導緻在一些低中端裝置上出現閃爍等現象；另外，每個合成層都具會占據額外的記憶體，這個數量通常比開發者以為的要大的多，尤其是在移動端這種硬體資源受限制的場景中，過量的記憶體使用分分鐘就會讓應用崩潰。

1. 使用

   transform

   實作動畫

   這可能是我們編寫動畫時聽到最多的建議了。例如使用

   left

   top

   來實作位置動畫時，絕對定位的元素會形成

   RenderLayer

   ，但是卻不符合提升為

   CompositingLayer

   的條件，是以動畫元素就會和

   Document

   處在同一個合成層裡，持續進行的動畫就會導緻

   Document

   這一層（通常是正常文檔流這一層，包含了大量的流式布局的元素）不斷重繪，進而影響渲染效率，如果能夠讓動畫的節點放到單獨的合成層裡，就可以避免這種大規模重繪，并借助

   GPU

   加速合成的能力加速整個渲染流程。

2. 排查被動提升的情形

   被動提升主要是指“兄弟元素相對層級低于自己但卻是一個合成層”的情形以及“發生堆疊遮擋的幾個元素中層級較低的元素被提升為合成層”的狀況。一般的解決方案是主動提升動畫元素的

   z-index

   值或者調整文檔結構中節點的先後順序，當然所有的結果都還需要通過測試來确認。

3. 考慮合成層的空間占用

   合成層的後端存儲是渲染後的像素點資料，它的體積可能會非常大，在使用大屏圖檔時需要盡可能将其壓縮至視覺可接受的範圍而不能一味追求高清，對于純色的元素，可以使用較小的尺寸并借助

   transform:scale

   來放大至需要的尺寸。

4. 實測為王

   任何方案都隻是一種思路，必須通過在真實環境測試驗證才能确認其有效性。