創(chuàng)建前端平移動畫為何 translate() 優(yōu)于 top/right/bottom/left

morgan 發(fā)布于2019-08-29 13:01 / 1257人閱讀

摘要：許多層還會因為過大與許多內(nèi)容重疊而導(dǎo)致過度繪制的情況發(fā)生，從而增加?xùn)鸥窕臅r間。關(guān)于這一點，在中也有所體現(xiàn)。

前言

研究這個問題的起因，源于我在閱讀作曲家與聽眾這篇文章時，看到的這樣一句話。

例如，我對很多開發(fā)者（不管新手還是老手）仍然使用 CSS 的 top 和 left 而不是 transform 創(chuàng)建平移動畫感到震驚，盡管只要你在除了 8 核 MacBook Pro 之外的設(shè)備上進(jìn)行過測試，就會發(fā)現(xiàn)幀率的差別極其明顯。

看到這句話我也同樣震驚，震驚之處正如作者所言，我就是從未在意過兩者差別而使用 top 和 left 創(chuàng)建平移動畫的人之一。那么為什么兩者會有區(qū)別，讓我們來一探究竟吧。

測試用例

其實很慚愧，早在2012年就有許多人在博文中闡述這一事實了，也因此，我能很輕松的找到非常棒的demo（來源見參考文獻(xiàn)），如下：

top、left實現(xiàn)基于關(guān)鍵幀的平移動畫

translate實現(xiàn)基于關(guān)鍵幀的平移動畫

相信讀者在把Macbook Pro增加到一定數(shù)量的時候，都能發(fā)現(xiàn)兩者之間的差異了吧。

深入背后

現(xiàn)在讓我們來探究其中的原因。打開Chrome dev tools，切到Performance選項，記錄一段時間后，選擇某一幀查看各個過程所占時間。

首先是top、left的時間線：

在這一幀中，我們看到多個步驟占用了CPU時間。

換到translate則變成了截然不同的樣子：

根本沒有CPU時間。我看了很多幀，除了少部分幀有0.1ms左右的腳本執(zhí)行時間之外，大部分幀的CPU時間都是0。

答案已經(jīng)很顯然了，使用translate來做平移運動，大部分時間都不需要CPU參與。這個結(jié)果和五年前的文章不太相同，但時間已經(jīng)過了五年，瀏覽器的優(yōu)化至此地步也不算出乎意料吧。

接下來我們打開Render，開啟Paint Flashing和Layer Borders。

對于top、left我們會看到如下情況：

其中綠框是瀏覽器重繪的區(qū)域，對于使用position的情況，瀏覽器要在動畫的執(zhí)行中不停地繪制綠框中的區(qū)域。

而對于transform則是另一幅場景：

我們可以看到transform的版本我們的MacBook圖片周圍會多一個框框，這是因為transform會生成一個新的層，而對這個圖層進(jìn)行變換，對于瀏覽器來說，是不需要重繪的。包括在我點擊“add 10 more macbook”之后，也只有插入元素的時候會引起重繪。同樣，新插入的“MacBook”也各自有獨立的圖層，不會引起重繪。

那么，Chrome創(chuàng)建層的標(biāo)準(zhǔn)是什么呢？在Accelerated Rendering in Chrome中有如下表述：

What else gets its own layer? Chrome’s heuristics here have evolved over time and continue to, but currently any of the following trigger layer creation:

3D or perspective transform CSS properties

Composited plugins (i.e. Flash)

Elements with CSS animation for their opacity or using an animated transform

Elements with accelerated CSS filters

Element has a descendant that has a compositing layer (in other words if the element has a child element that’s in its own layer)

Element has a sibling with a lower z-index which has a compositing layer (in other words the it’s rendered on top of a composited layer)

所以，對于我們的transform動畫，其符合上述第五條規(guī)則中的“using an animated transform”，因此會創(chuàng)建自己獨立的層；同樣，我們也可以根據(jù)上述規(guī)則來給top、left方案創(chuàng)建獨立的層來減少重繪。

接下來，根據(jù)第一條規(guī)則，讓我們在top、left示例中的.macbook類上面加上這樣一行css：

transform: translateZ(0);

我們就能看到和translate方案一樣的場景了。

通過查閱資料，我簡單說一下我的理解。Chrome會預(yù)先將層的內(nèi)容繪制成位圖發(fā)送給GPU，如果層僅僅是位置與透明度等特定的一些屬性發(fā)生變化，而不是內(nèi)容發(fā)生變化，則無需重繪這一位圖。因此無論是translate動畫方案，還是加上3D變換屬性的top、left方案，由于其都在獨立的層上，且只是發(fā)生位置變化，因此無需重繪。

然而，層并不是越多越好。參考Accelerated Rendering in Chrome中的表述。

But beware just blindly creating them, as they’re not free: they take up memory in system RAM and on the GPU (particularly limited on mobile devices) and having lots of them can introduce other overhead in the logic keeps track of which are visible. Many layers can also actually increase time spent rasterizing if they layers are large and overlap a lot where they didn’t previously, leading to what’s sometimes referred to as “overdraw”. So use your knowledge wisely!

簡單翻譯一下就是：層會占用系統(tǒng) RAM 與 GPU(在移動設(shè)備上尤其有限)的內(nèi)存，并且擁有大量的層會因為記錄哪些是可見的而引入額外的開銷。許多層還會因為過大與許多內(nèi)容重疊而導(dǎo)致“過度繪制(overdraw)”的情況發(fā)生，從而增加?xùn)鸥窕臅r間。關(guān)于這一點，在Jank Busting Apple"s Home Page中也有所體現(xiàn)。

In this case, too many elements have translateZ(0) applied when only one or two applications are really needed. This is forcing a longer composite time and ultimately giving the animations some jank.

“So use your knowledge wisely!”

參考文獻(xiàn)

A Tale of Animation Performance

Why Moving Elements With Translate() Is Better Than Pos:abs Top/left

Accelerated Rendering in Chrome

Jank Busting Apple"s Home Page