CSS3 動(dòng)畫(huà)卡頓性能優(yōu)化的完美解決方案

來(lái)源：懂視網(wǎng) 責(zé)編：小采時(shí)間：2020-11-27 22:07:25

CSS3 動(dòng)畫(huà)卡頓性能優(yōu)化的完美解決方案

CSS3 動(dòng)畫(huà)卡頓性能優(yōu)化的完美解決方案:為什么會(huì)卡頓？有一個(gè)前提必須要提，前端開(kāi)發(fā)者們都知道，瀏覽器是單線(xiàn)程運(yùn)行的。但是我們要明確以下幾個(gè)概念：?jiǎn)尉€(xiàn)程，主線(xiàn)程和合成線(xiàn)程。雖然說(shuō)瀏覽器執(zhí)行js是單線(xiàn)程執(zhí)行（注意，是執(zhí)行，并不是說(shuō)瀏覽器只有1個(gè)線(xiàn)程，而是運(yùn)行時(shí)，runing），但實(shí)際上瀏覽

推薦度：

點(diǎn)擊下載本文 文檔為doc格式

導(dǎo)讀CSS3 動(dòng)畫(huà)卡頓性能優(yōu)化的完美解決方案:為什么會(huì)卡頓？有一個(gè)前提必須要提，前端開(kāi)發(fā)者們都知道，瀏覽器是單線(xiàn)程運(yùn)行的。但是我們要明確以下幾個(gè)概念：?jiǎn)尉€(xiàn)程，主線(xiàn)程和合成線(xiàn)程。雖然說(shuō)瀏覽器執(zhí)行js是單線(xiàn)程執(zhí)行（注意，是執(zhí)行，并不是說(shuō)瀏覽器只有1個(gè)線(xiàn)程，而是運(yùn)行時(shí)，runing），但實(shí)際上瀏覽

為什么會(huì)卡頓？

有一個(gè)前提必須要提，前端開(kāi)發(fā)者們都知道，瀏覽器是單線(xiàn)程運(yùn)行的。但是我們要明確以下幾個(gè)概念：?jiǎn)尉€(xiàn)程，主線(xiàn)程和合成線(xiàn)程。
雖然說(shuō)瀏覽器執(zhí)行js是單線(xiàn)程執(zhí)行（注意，是執(zhí)行，并不是說(shuō)瀏覽器只有1個(gè)線(xiàn)程，而是運(yùn)行時(shí)，runing），但實(shí)際上瀏覽器的2個(gè)重要的執(zhí)行線(xiàn)程，這 2 個(gè)線(xiàn)程協(xié)同工作來(lái)渲染一個(gè)網(wǎng)頁(yè)：主線(xiàn)程和合成線(xiàn)程。
一般情況下，主線(xiàn)程負(fù)責(zé)：運(yùn)行 JavaScript；計(jì)算 HTML 元素的 CSS 樣式；頁(yè)面的布局；將元素繪制到一個(gè)或多個(gè)位圖中；將這些位圖交給合成線(xiàn)程。
相應(yīng)地，合成線(xiàn)程負(fù)責(zé)：通過(guò) GPU 將位圖繪制到屏幕上；通知主線(xiàn)程更新頁(yè)面中可見(jiàn)或即將變成可見(jiàn)的部分的位圖；計(jì)算出頁(yè)面中哪部分是可見(jiàn)的；計(jì)算出當(dāng)你在滾動(dòng)頁(yè)面時(shí)哪部分是即將變成可見(jiàn)的；當(dāng)你滾動(dòng)頁(yè)面時(shí)將相應(yīng)位置的元素移動(dòng)到可視區(qū)域。

那么為什么會(huì)造成動(dòng)畫(huà)卡頓呢？

原因就是主線(xiàn)程和合成線(xiàn)程的調(diào)度不合理。
下面來(lái)詳細(xì)說(shuō)一下調(diào)度不合理的原因：

在使用height，width，margin，padding作為transition的值時(shí)，會(huì)造成瀏覽器主線(xiàn)程的工作量較重，例如從margin-left：-20px渲染到margin-left:0，主線(xiàn)程需要計(jì)算樣式margin-left:-19px,margin-left:-18px，一直到margin-left:0，而且每一次主線(xiàn)程計(jì)算樣式后，合成進(jìn)程都需要繪制到GPU然后再渲染到屏幕上，前后總共進(jìn)行20次主線(xiàn)程渲染，20次合成線(xiàn)程渲染，20+20次，總計(jì)40次計(jì)算。

主線(xiàn)程的渲染流程，可以參考瀏覽器渲染網(wǎng)頁(yè)的流程：

使用 HTML 創(chuàng)建文檔對(duì)象模型（DOM）
使用 CSS 創(chuàng)建 CSS 對(duì)象模型（CSSOM）
基于 DOM 和 CSSOM 執(zhí)行腳本（Scripts）
合并 DOM 和 CSSOM 形成渲染樹(shù)（Render Tree）
使用渲染樹(shù)布局（Layout）所有元素
渲染（Paint）所有元素

也就是說(shuō)，主線(xiàn)程每次都需要執(zhí)行Scripts，Render Tree ,Layout和Paint這四個(gè)階段的計(jì)算。

而如果使用transform的話(huà)，例如tranform:translate(-20px,0)到transform:translate(0,0)，主線(xiàn)程只需要進(jìn)行一次tranform:translate(-20px,0)到transform:translate(0,0)，然后合成線(xiàn)程去一次將-20px轉(zhuǎn)換到0px，這樣的話(huà)，總計(jì)1+20計(jì)算。

可能會(huì)有人說(shuō)，這才提升了19次，有什么好性能提升的？
假設(shè)一次10ms。
那么就減少了約190ms的耗時(shí)。
會(huì)有人說(shuō)，辣雞，才190ms，無(wú)所謂。
那么如果margin-left是從-200px到0呢，一次10ms，10ms*199≈2s。
還會(huì)有人說(shuō)，辣雞，也就2s，無(wú)所謂。
你忘了單線(xiàn)程這回事了嗎？
如果網(wǎng)頁(yè)有3個(gè)動(dòng)畫(huà)，3*2s=6s，就是6s的性能提升。
由于數(shù)據(jù)是猜測(cè)的，所以暫時(shí)不考慮其真實(shí)性

為了增強(qiáng)本文的說(shuō)服力，下面我就用一個(gè)實(shí)例來(lái)證實(shí)下我的觀點(diǎn)，大家一起看一下

前端時(shí)間用 animation 實(shí)現(xiàn) H5 頁(yè)面中首頁(yè)動(dòng)畫(huà)過(guò)渡，很簡(jiǎn)單的一個(gè)效果，首頁(yè)加載一個(gè)客服頭像，先放大，停留 700ms 后再縮小至頂部。代碼如下：

<!DOCTYPE html>
<html>
<head lang="zh-cn">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=1" >
 <script type="text/javascript" src="http://apps.bdimg.com/libs/jquery/2.1.1/jquery.min.js"></script>
 <title>首頁(yè)加載動(dòng)畫(huà)</title>
 <head>
 <style>
 .welcome-main{
 display: none; 
 padding-bottom: 40px; 
 }
 .top-info{ 
 width: 100%; 
 position: absolute; 
 left: 0; 
 top: 93px; 
 }
 .wec-img{
 width: 175px; 
 height: 175px; 
 position: relative; 
 padding: 23px; 
 box-sizing: border-box; 
 margin: 0 auto; 
 }
 .wec-img:before{ 
 content: ''; 
 position: absolute; 
 left: 0; 
 top: 0; 
 width: 100%; 
 height: 100%; 
 background: url("./images/kf-welcome-loading.png"); 
 background-size: 100%; 
 }
 .wec-img .img-con{
 width: 100%; 
 height: 100%; 
 border-radius: 50%; 
 /*box-sizing: border-box;*/
 background: url("./images/kf_1.jpg"); 
 background-size: 100%; 
 padding: 1px; 
 }
 .wec-img .img-con img{
 width: 100%; 
 height: 100%; 
 border-radius: 50%; 
 }
 .loaded .wec-img{
 -webkit-transform-origin: center top; 
 } 
 .loading.welcome-main{
 display: block;
 }
 .loading .wec-img{
 -webkit-animation:fadeIn .3s ease both;
 }
 .loading .wec-img:before{
 -webkit-animation:rotate .6s .2s linear both; 
 }
 .loaded .top-info{
 -webkit-animation:mainpadding 1s 0s ease both; 
 }
 .loaded .wec-img{
 -webkit-animation:imgSmall 1s 0s ease both; }
 @-webkit-keyframes mainpadding{
 0%{-webkit-transform:translateY(0) 
 }
 100%{-webkit-transform:translateY(-87px) 
 }
 } 
 @-webkit-keyframes imgSmall{
 0%{
 width: 175px; 
 height: 175px; 
 padding: 23px; 
 }
 100%{ 
 width: 60px; 
 height: 60px; 
 padding: 0; 
 }
 } 
 @-webkit-keyframes fadeIn{
 0%{opacity:0;-webkit-transform:scale(.3)}
 100%{opacity:1;-webkit-transform:scale(1)}
 } 
 @-webkit-keyframes rotate{
 0%{opacity:0;-webkit-transform:rotate(0deg);}
 50%{opacity:1;-webkit-transform:rotate(180deg);}
 100%{opacity:0;-webkit-transform:rotate(360deg);}
 } 
 </style>
 <body>
 <div class="welcome-main">
 <div class="top-info">
 <div class="wec-img"><p class="img-con"><img src="" alt=""></p></div>
 </div>
 </div>
 <script>
 $('.welcome-main').addClass('loading');
 setTimeout(function(){
 $('.hi.fst').removeClass('loading');
 $('.welcome-main').addClass('loaded');
 },700);
 </script>
 </body>
 </html>

在 chrome 上測(cè)試 ok，但在提測(cè)給 QA 的時(shí)候發(fā)現(xiàn)部分機(jī)型，如華為(系統(tǒng)4.2)，oppo(系統(tǒng)5.1)的出現(xiàn)卡頓情況。

百思不得其解，后來(lái)參考文章深入瀏覽器理解 CSS animations 和 transitions 的性能問(wèn)題一文，將圖片縮放中動(dòng)畫(huà)元素改成 transform，如下

@-webkit-keyframes imgSmall{
 0%{
 -webkit-transform:scale(1);
 }
 100%{
 -webkit-transform:scale(.465);
 }
}

果然啊，卡頓問(wèn)題解決了。

文章深入瀏覽器理解 CSS animations 和 transitions 的性能問(wèn)題是這么解釋的，現(xiàn)代的瀏覽器通常會(huì)有兩個(gè)重要的執(zhí)行線(xiàn)程，這 2 個(gè)線(xiàn)程協(xié)同工作來(lái)渲染一個(gè)網(wǎng)頁(yè)：主線(xiàn)程和合成線(xiàn)程。

一般情況下，主線(xiàn)程負(fù)責(zé)：運(yùn)行 JavaScript；計(jì)算 HTML 元素的 CSS 樣式；頁(yè)面的布局；將元素繪制到一個(gè)或多個(gè)位圖中；將這些位圖交給合成線(xiàn)程。

相應(yīng)地，合成線(xiàn)程負(fù)責(zé)：通過(guò) GPU 將位圖繪制到屏幕上；通知主線(xiàn)程更新頁(yè)面中可見(jiàn)或即將變成可見(jiàn)的部分的位圖；計(jì)算出頁(yè)面中哪部分是可見(jiàn)的；計(jì)算出當(dāng)你在滾動(dòng)頁(yè)面時(shí)哪部分是即將變成可見(jiàn)的；當(dāng)你滾動(dòng)頁(yè)面時(shí)將相應(yīng)位置的元素移動(dòng)到可視區(qū)域。

假設(shè)我們要一個(gè)元素的 height 從 100 px 變成 200 px，就像這樣：

div {
 height: 100px;
 transition: height 1s linear;
}
 
div:hover {
 height: 200px;
}

主線(xiàn)程和合成線(xiàn)程將按照下面的流程圖執(zhí)行相應(yīng)的操作。注意在橘黃色方框的操作可能會(huì)比較耗時(shí)，在藍(lán)色框中的操作是比較快速的。

而使用 transform:scale 實(shí)現(xiàn)

div {
 transform: scale(0.5);
 transition: transform 1s linear;
}
 
div:hover {
 transform: scale(1.0);
}

此時(shí)流程如下：

也就是說(shuō)，使用 transform，瀏覽器只需要一次生成這個(gè)元素的位圖，并在動(dòng)畫(huà)開(kāi)始的時(shí)候?qū)⑺峤唤o GPU 去處理。之后，瀏覽器不需要再做任何布局、繪制以及提交位圖的操作。從而，瀏覽器可以充分利用 GPU 的特長(zhǎng)去快速地將位圖繪制在不同的位置、執(zhí)行旋轉(zhuǎn)或縮放處理。

為了從數(shù)量級(jí)上去證實(shí)這個(gè)理論，我打開(kāi) chrome 的 Timeline 查看頁(yè)面 FPS

其中，當(dāng)用 height 做動(dòng)畫(huà)元素時(shí)，在切換過(guò)程的 FPS 只有 44，我們知道每秒 60 幀是最適合人眼的交互，小于 60，人眼能明顯感覺(jué)到，這就是為什么卡頓的原因。

rendering 和 painting 所花的時(shí)間如下：

再來(lái)看看用 transform:scale

FPS 達(dá)到 66，且 rendering 和 painting 時(shí)間減少了 3 倍。

到此為止問(wèn)題是解決了，隔了幾天，看到一篇解決 Chrome 動(dòng)畫(huà)”卡頓”的辦法，發(fā)現(xiàn)還能通過(guò)開(kāi)啟硬件加速的方式優(yōu)化動(dòng)畫(huà)，于是又試了一遍。

webkit-transform: translate3d(0,0,0);
-moz-transform: translate3d(0,0,0);
-ms-transform: translate3d(0,0,0);
-o-transform: translate3d(0,0,0);
transform: translate3d(0,0,0);

驚人的事情發(fā)生了，F(xiàn)PS 達(dá)到 72：