CSS3动画性能优化——让硬件加个速

版权声明:本文为博主原创文章,未经博主允许不得转载,博客地址:https://blog.csdn.net/weixin_44309019博主邮箱: [email protected] 作者:水果烫瓜皮 来源:CSDN https://blog.csdn.net/weixin_44309019/article/details/88771449

最近翻阅了很多有关CSS3动画性能优化的技术博客,学到了很多东西,受益匪浅啊。多花一点时间也要把这篇文章撸出来。毕竟是干货满满的经验总结。

浏览器渲染主流程

当我们的渲染引擎取得了我们的文档内容之后它的基本流程是这样实现的:
解析html以构建树形的数据结构(dom tree) > 构建render树 > 布局render树 > 绘制render树
若对render树不清楚的,可以去看Render树与CSS解析

主线程的渲染流程,可以参考大部分浏览器渲染网页的流程:

  • 使用 HTML 创建文档对象模型(DOM)
  • 使用 CSS 创建 CSS 对象模型(CSSOM)
  • 基于 DOM 和 CSSOM执行脚本(Scripts)
  • 合并 DOM 和 CSSOM 形成渲染树(Render Tree)
  • 使用渲染树布局(Layout)所有元素
  • 渲染(Paint)所有元素

也就是说,主线程每次都需要执行Scripts,Render Tree ,Layout和Paint这四个阶段的计算。

动画卡顿的原因

导致这样动画卡顿的原因:主线程和合成线程调度不合理。
当我们把left、right、top、bottom设置为transition的值,会造成浏览器负担压力很大。
举个栗子
我们设置为margin-right:-30px渲染到0px。那么它的主线程会渲染从30-29-28-…-0.这样主线程就渲染了30次。再加上,合成主线程之后会绘制到GPU上再渲染到页面上。所以就是进行了30次主线程渲染,30次合成线程渲染,就是60次运算!

你这样做出来的动画,基本上都是卡顿状。这也是理所当然的,计算量这么大。

欺骗浏览器——触发硬件加速

浏览器的现状

  • 在CSS的动画、变形、渐变并不会自动的触发GPU加速,而是使用浏览器稍慢的软件渲染引擎。
  • 在transition,transform和animation的世界里,应该卸载进程到GPU以加快速度。
  • 只有3D变形会有自己的layer,2D变形不会。

translateZ()(or translate3d())Hack
为元素添加没有变化的3D变形,骗取浏览器触发硬件加速。
加速原理
在使用css3 transtion做动画效果时,优先选择transform,尽量不要使用height,width,margin,padding,box-shadows与gradients。box-shadows与gradients往往都是页面的性能杀手,尤其是在一个元素同时都使用了它们.尽可能的让动画元素不在文档流中,以减少重排。

这样做是提升了其性能,有利既有弊。那么它的代价:

这种情况通过向它自己的层叠加元素,占用RAM和GPU存储空间。

性能消耗图
性能消耗如图
由上面的性能消耗如图,我们能够清楚的看出。opacity和transform的性能是最好的。

扫描二维码关注公众号,回复: 5637011 查看本文章

好了除了我们现在讲到的骗取浏览器使用GPU加速的transform属性,以及opacity之外。我们现在还有另外一种方案。

巧用will-change

提前通知浏览器元素将要做什么动画,让浏览器提前准备合适的优化设置。

虽然CSS3的will-changge方便是方便但是它的兼容性还有待提升。
兼容性:

  • IE13+
  • FireFox47+
  • Chrome49+
  • Safari9.1+
  • Opera39+
  • IOS9.3+
  • Android52+

用will-change提示浏览器关于即将发生的变形十分简单,添加个CSS属性就行
will-change: transform;

也可以告诉浏览器要改变元素的滚动条位置,或者多个要变化的属性,写下属性的名字就行,也可以写多个,逗号隔开

will-change: transform, opacity;
声明了元素即将进行的变化会让浏览器在渲染页面时做更好的决定,这明显比之前说的3D hacks要好。

注意事项:
勿滥用、提前申明、remove。

猜你喜欢

转载自blog.csdn.net/weixin_44309019/article/details/88771449