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

目錄

示例代碼託管在:

博客園地址:

華為雲社區地址:

一. 硬件加速相關的幾個概念

之前介紹到了RenderLayer渲染層的概念,在涉及到硬件加速的話題時,出現了很多新的概念,參考《Webkit技術內幕》一書的介紹總結如下:

Webkit決定將哪些RenderLayer對象組合在一起,形成一個有後端存儲的新層,這一新層不久後會用於合成,這裏稱之為合成層CompositingLayer)。每一個合成層都會對應一個或多個後端存儲,由RenderLayerBacking類進行統一管理,後端存儲空間使用GraphicsLayer來表示,也就是說RenderLayerBacking管理着一個或多個與對應的合成層有關的GraphicsLayer

筆者旁白:對於渲染過程來說,只需要理解這裏形成了新的CompositingLayer合成層就可以了,其他的層概念基本都是用於實現對CompositingLayer功能支持的,概念數量太多對於理解宏觀流程是一大障礙。

二. 合成層的生成條件

顯式提升

合成層的處理是依賴於硬件加速的,但是GPU的存儲空間有限最好不要濫用,過多的合成層有可能還會造成相反的效果,所以瀏覽器只會將滿足下列任意條件的RenderLayer提升為CompositingLayer

  • 具有CSS3D屬性或CSS透視效果
  • 包含的RenderObject節點表示的是使用硬件加速的視頻解碼技術的HTML5video元素
  • 包含的RenderObject節點包含使用了硬件加速的Canvas2DWebGL技術
  • 使用了CSS透明效果或CSS變形動畫
  • 使用了硬件加速的CSS Filters技術(有的文獻中表示filters屬性並沒有提升為合成層的效果,推測只有一部分filters濾鏡效果需要使用硬件加速,並非所有)
  • 使用了剪裁Clip或者反射Reflection,並且它的後代中包含一個合成層
  • 擁有一個Z坐標比自己小的兄弟節點,且該節點是一個合成層。

上面的規則里我們最熟悉的可能就是transform:translateZ(0)或者在關鍵幀動畫的定義中改變transformopacity屬性。當然,隨着技術的演進,上面的規則並不一定全面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這篇中的示例更加詳細,子元素引發父元素提升,父元素又引發兄弟元素提升。

三. 硬件加速的權衡

所有的技術方案都是有代價的,這是亘古不變的道理,合成層的好處很明顯,GPUCPU的處理速度快很多,觸發repaint重繪時,只需要重繪獨立的層,然後重新合成即可,不需要重繪整個畫面。但它也存在一些弊端:首先是數據傳輸的問題,CPUGPU的關係就好比客戶端和服務端一樣,它們的協作是需要傳輸數據的,當層的數量達到一定量級后,傳輸的速度就會影響到整體的處理效率,進而導致在一些低中端設備上出現閃爍等現象;另外,每個合成層都具會佔據額外的內存,這個數量通常比開發者以為的要大的多,尤其是在移動端這種硬件資源受限制的場景中,過量的內存使用分分鐘就會讓應用崩潰。

四. 動畫實現的一些建議

  1. 使用transform實現動畫

    這可能是我們編寫動畫時聽到最多的建議了。例如使用lefttop來實現位置動畫時,絕對定位的元素會形成RenderLayer,但是卻不符合提升為CompositingLayer的條件,所以動畫元素就會和Document處在同一個合成層里,持續進行的動畫就會導致Document這一層(通常是正常文檔流這一層,包含了大量的流式布局的元素)不斷重繪,從而影響渲染效率,如果能夠讓動畫的節點放到單獨的合成層里,就可以避免這種大規模重繪,並藉助GPU加速合成的能力加速整個渲染流程。

  2. 排查被動提升的情形

    被動提升主要是指“兄弟元素相對層級低於自己但卻是一個合成層”的情形以及“發生堆疊遮擋的幾個元素中層級較低的元素被提升為合成層”的狀況。一般的解決方案是主動提升動畫元素的z-index值或者調整文檔結構中節點的先後順序,當然所有的結果都還需要通過測試來確認。

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

    合成層的後端存儲是渲染后的像素點數據,它的體積可能會非常大,在使用大屏圖片時需要盡可能將其壓縮至視覺可接受的範圍而不能一味追求高清,對於純色的元素,可以使用較小的尺寸並藉助transform:scale來放大至需要的尺寸。

  4. 實測為王

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

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

小三通海運與一般國際貿易有何不同?

小三通快遞通關作業有哪些?

您可能也會喜歡…