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,10ms*199≈2s。
还会有⼈说,辣鸡,也就2s,⽆所谓。
你忘了单线程这回事了吗?
如果⽹页有3个动画,3*2s=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="apps.bdimg/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>js控制css3动画触发
</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;
}
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 动画卡顿⽅案
1.尽量使⽤ transform 当成动画熟悉,避免使⽤ height,width,margin,padding 等;
2.要求较⾼时,可以开启浏览器开启 GPU 硬件加速。
总结
以上就是这篇⽂章的全部内容了,希望本⽂的内容对⼤家的学习或者⼯作具有⼀定的参考学习价值,谢谢⼤家对的⽀持。如果你想了解更多相关内容请查看下⾯相关链接
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论