CSS3 動畫卡頓解決方案
為什麼會卡頓?
有一個前提必須要提,前端開發者們都知道,瀏覽器是單執行緒執行的。但是我們要明確以下幾個概念:單執行緒,主執行緒和合成執行緒。
雖然說瀏覽器執行js是單執行緒執行(注意,是執行,並不是說瀏覽器只有1個執行緒,而是執行時,runing),但實際上瀏覽器的2個重要的執行執行緒,這 2 個執行緒協同工作來渲染一個網頁:主執行緒和合成執行緒。
一般情況下,主執行緒負責:執行 JavaScript;計算 HTML 元素的 CSS 樣式;頁面的佈局;將元素繪製到一個或多個位圖中;將這些點陣圖交給合成執行緒。
相應地,合成執行緒負責:通過 GPU 將點陣圖繪製到螢幕上;通知主執行緒更新頁面中可見或即將變成可見的部分的點陣圖;計算出頁面中哪部分是可見的;計算出當你在滾動頁面時哪部分是即將變成可見的;當你滾動頁面時將相應位置的元素移動到可視區域。
那麼為什麼會造成動畫卡頓呢?
原因就是主執行緒和合成執行緒的排程不合理。
下面來詳細說一下排程不合理的原因:
在使用height,width,margin,padding作為transition的值時,會造成瀏覽器主執行緒的工作量較重,例如從margin-left:-20px渲染到margin-left:0,主執行緒需要計算樣式margin-left:-19px,margin-left:-18px,一直到margin-left:0,而且每一次主執行緒計算樣式後,合成程序都需要繪製到GPU然後再渲染到螢幕上,前後總共進行20次主執行緒渲染,20次合成執行緒渲染,20+20次,總計40次計算。
主執行緒的渲染流程,可以參考瀏覽器渲染網頁的流程:
使用 HTML 建立文件物件模型(DOM)
使用 CSS 建立 CSS 物件模型(CSSOM)
基於 DOM 和 CSSOM 執行指令碼(Scripts)
合併 DOM 和 CSSOM 形成渲染樹(Render Tree)
使用渲染樹佈局(Layout)所有元素
渲染(Paint)所有元素
也就是說,主執行緒每次都需要執行Scripts,Render Tree ,Layout和Paint這四個階段的計算。
而如果使用transform的話,例如tranform:translate(-20px,0)到transform:translate(0,0),主執行緒只需要進行一次tranform:translate(-20px,0)到transform:translate(0,0),然後合成執行緒去一次將-20px轉換到0px,這樣的話,總計1+20計算。
可能會有人說,這才提升了19次,有什麼好效能提升的?
假設一次10ms。
那麼就減少了約190ms的耗時。
會有人說,辣雞,才190ms,無所謂。
那麼如果margin-left是從-200px到0呢,一次10ms,10ms199≈2s。
還會有人說,辣雞,也就2s,無所謂。
你忘了單執行緒這回事了嗎?
如果網頁有3個動畫,32s=6s,就是6s的效能提升。
由於資料是猜測的,所以暫時不考慮其真實性
為了增強本文的說服力,下面我就用一個例項來證實下我的觀點,大家一起看一下
前端時間用 animation 實現 H5 頁面中首頁動畫過渡,很簡單的一個效果,首頁載入一個客服頭像,先放大,停留 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>首頁載入動畫</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 上測試 ok,但在提測給 QA 的時候發現部分機型,如華為(系統4.2),oppo(系統5.1)的出現卡頓情況。
百思不得其解,後來參考文章深入瀏覽器理解 CSS animations 和 transitions 的效能問題一文,將圖片縮放中動畫元素改成 transform,如下
@-webkit-keyframes imgSmall{
0%{
-webkit-transform:scale(1);
}
100%{
-webkit-transform:scale(.465);
}
}
果然啊,卡頓問題解決了。
文章深入瀏覽器理解 CSS animations 和 transitions 的效能問題是這麼解釋的,現代的瀏覽器通常會有兩個重要的執行執行緒,這 2 個執行緒協同工作來渲染一個網頁:主執行緒和合成執行緒。
一般情況下,主執行緒負責:執行 JavaScript;計算 HTML 元素的 CSS 樣式;頁面的佈局;將元素繪製到一個或多個位圖中;將這些點陣圖交給合成執行緒。
相應地,合成執行緒負責:通過 GPU 將點陣圖繪製到螢幕上;通知主執行緒更新頁面中可見或即將變成可見的部分的點陣圖;計算出頁面中哪部分是可見的;計算出當你在滾動頁面時哪部分是即將變成可見的;當你滾動頁面時將相應位置的元素移動到可視區域。
假設我們要一個元素的 height 從 100 px 變成 200 px,就像這樣:
div {
height: 100px;
transition: height 1s linear;
}
div:hover {
height: 200px;
}
主執行緒和合成執行緒將按照下面的流程圖執行相應的操作。注意在橘黃色方框的操作可能會比較耗時,在藍色框中的操作是比較快速的。
而使用 transform:scale 實現
div {
transform: scale(0.5);
transition: transform 1s linear;
}
div:hover {
transform: scale(1.0);
}
此時流程如下:
也就是說,使用 transform,瀏覽器只需要一次生成這個元素的點陣圖,並在動畫開始的時候將它提交給 GPU 去處理 。之後,瀏覽器不需要再做任何佈局、 繪製以及提交點陣圖的操作。從而,瀏覽器可以充分利用 GPU 的特長去快速地將點陣圖繪製在不同的位置、執行旋轉或縮放處理。
為了從數量級上去證實這個理論,我開啟 chrome 的 Timeline 檢視頁面 FPS
其中,當用 height 做動畫元素時,在切換過程的 FPS 只有 44,我們知道每秒 60 幀是最適合人眼的互動,小於 60,人眼能明顯感覺到,這就是為什麼卡頓的原因。
rendering 和 painting 所花的時間如下:
再來看看用 transform:scale
FPS 達到 66,且 rendering 和 painting 時間減少了 3 倍。
到此為止問題是解決了,隔了幾天,看到一篇解決 Chrome 動畫”卡頓”的辦法,發現還能通過開啟硬體加速的方式優化動畫,於是又試了一遍。
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);
驚人的事情發生了,FPS 達到 72:
總結解決 CSS3 動畫卡頓方案
儘量使用 transform 當成動畫熟悉,避免使用 height,width,margin,padding 等;
要求較高時,可以開啟瀏覽器開啟 GPU 硬體加速。
為了幫助大家讓學習變得輕鬆、高效,給大家免費分享一大批資料,幫助大家在成為全棧工程師,乃至架構師的路上披荊斬棘。在這裡給大家推薦一個前端全棧學習交流圈:866109386.歡迎大家進群交流討論,學習交流,共同進步。
當真正開始學習的時候難免不知道從哪入手,導致效率低下影響繼續學習的信心。
但最重要的是不知道哪些技術需要重點掌握,學習時頻繁踩坑,最終浪費大量時間,所以有有效資源還是很有必要的。
最後祝福所有遇到瓶疾且不知道怎麼辦的前端程式設計師們,祝福大家在往後的工作與面試中一切順利。