CSS3 动画卡顿性能优化的完美解决方案

2024-10-08 15:34:48

为什么会卡顿？

有一个前提必须要提，前端开发者们都知道，浏览器是单线程运行的。但是我们要明确以下几个概念：单线程，主线程和合成线程。
虽然说浏览器执行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="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 动画卡顿方案

1.尽量使用 transform 当成动画熟悉，避免使用 height,width,margin,padding 等；
2.要求较高时，可以开启浏览器开启 GPU 硬件加速。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对我们的支持。如果你想了解更多相关内容请查看下面相关链接

javascript+html5+css3自定义弹出窗口效果

本文实例为大家分享了js自定义弹出窗口效果展示的具体代码,供大家参考,具体内容如下效果图: 源码: 1.demo.jsp <%@ page contentType="text/html;charset=UTF-8" language="java" %> <html> <head> <title>自定义弹出窗口</title> <script type="text/javascript&qu
js css3实现图片拖拽效果

本文实例为大家分享了css3实现图片拖拽效果的具体代码,供大家参考,具体内容如下 <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title></title> <style type="text/css"> body{ text-align: center; } .container{ display: flex; just
js+css3实现旋转效果

我的前面一张文章实现了用css3制作旋转的效果,现在呢,我换另外一种方法来实现.就是使用js结合css3的方法来实现的.下面我就先上图给大家看看效果吧下面呢我先放上我的css代码,代码很简单: .one{ width:200px; height: 200px; border:1px solid #adadad; transition:all 0.1s; border-radius:50%; background:url(images/1.jpg) no-repeat center center
详解vue+css3做交互特效的方法

1.前言做项目就难免会开发交互效果或者特效,而我最近开发的项目一直在使用vue,开发技术栈方面,理所当然就使用了vue+css3开发,过程中发现使用vue+css3开发特效,和javascript/jquery+css3的思维方式不一样,但是比javascript/jquery+css3简单一点点.今天就分享三个简单的小实例,希望能起到拓展思维的作用,让大家明白vue+css3应该怎样开发交互效果!如果大家有什么好的建议,或者觉得我哪里写错了,欢迎指出! 1.文章上面的代码,虽然代码很简单,不
JavaScript判断浏览器对CSS3属性是否支持的多种方法

前言 CSS3的出现让浏览器的表现更加的丰富多彩,表现冲击最大的就是动画了,在日常书写动画的时候,很有必要去事先判断浏览器是否支持,尤其是在写CSS3动画库的时候.比如transition的animation-play-state,就只有部分浏览器支持. 下面的方法可以使用脚本判断浏览器是否支持某一个CSS3属性: 第一种:javascript比较常用下面这个代码: var support_css3 = (function() { var div = document.createElement
fullPage.js和CSS3实现全屏滚动效果

首先说一下fullpage,它是一个jquery的插件,用来实现鼠标向上向下滑动,就会自动切换到上一屏或者下一屏,对于要做一些高大上的效果确实是一个很好的插件.首先先展示一下基本的效果图. 总共有四屏的内容当鼠标每次上下滑动时就会一整屏的切换. 第一屏是用一个图片,其他的三屏都是由左侧的三个图片和右侧的两个图片组成的. 这三屏左侧的图片展开方式不同,所以就更有炫酷的效果. 第二屏的三个图片是当页面显示时从下到上依次出来到正确的位置. 第三屏的三个图片是当页面显示时从左到右依次展开到正确的位置.
jQuery+CSS3实现点赞功能

效果图: 图(1) 初始图图(2) 点击后代码如下: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <m
javascript+css3开发打气球小游戏完整代码

效果知识点: css3画气球, 自定义属性运用,随机阵列, DOM元素操作,高级回调函数与参数复传,动态布局,鼠标事件,定时器运用,CSS3新增样式等. css代码如下: <style> {margin:0;padding:0;} body{background:#434343;overflow:hidden} .balloon{ position:absolute; left:0; top:0; margin:auto; width:160px; height:160px; 圆角: 左上右
JS+CSS3制作炫酷的弹窗效果

昨天在家看电视时,退出的时候发现了一个弹窗效果,整个背景模糊,觉得这样的效果好炫,要比纯色加透明度高大上好多,连续试了几个界面,最终确定效果由css实现的,于是今天一大早来到公司便赶紧搜索了一下,虽然兼容性奇差,但是一个css属性就可以搞定.瞬间感觉自己知道的真是太少了~~ 首先回忆一下弹窗的实现,一般我们分为两层,弹出窗口层(popus)和遮罩层(mask),通常情况下我习惯就这两元素全部设成fixed定位,具体和absolute区别一试便知.对于mask层自不用多少,我们如下给他设置属性,让
CSS3 动画卡顿性能优化的完美解决方案

为什么会卡顿? 有一个前提必须要提,前端开发者们都知道,浏览器是单线程运行的.但是我们要明确以下几个概念:单线程,主线程和合成线程. 虽然说浏览器执行js是单线程执行(注意,是执行,并不是说浏览器只有1个线程,而是运行时,runing),但实际上浏览器的2个重要的执行线程,这 2 个线程协同工作来渲染一个网页:主线程和合成线程. 一般情况下,主线程负责:运行 JavaScript:计算 HTML 元素的 CSS 样式:页面的布局:将元素绘制到一个或多个位图中:将这些位图交给合成线程. 相应地,合
Android使用ViewPager快速切换Fragment时卡顿的优化方案

当ViewPager切换到当前的Fragment时,Fragment会加载布局并显示内容,如果用户这时快速切换ViewPager,即Fragment需要加载UI内容,而又频繁地切换Fragment,就容易产生卡顿现象(类似在ListView快速滑动的同时加载图片容易卡顿). 优化方案: 1.Fragment轻量化如果ViewPager加载的Fragment都比较轻量,适当精简Fragment的布局,可提高Fragment加载的速度,从而减缓卡顿现象. 2.防止Fragment被销毁 ViewP
Android APP性能优化分析

本文通过Android APP性能优化的四个方面做了详细分析,并对原理和重点做了详细解释,以下是全部内容: 说到 Android 系统手机,大部分人的印象是用了一段时间就变得有点卡顿,有些程序在运行期间莫名其妙的出现崩溃,打开系统文件夹一看,发现多了很多文件,然后用手机管家 APP 不断地进行清理优化 ,才感觉运行速度稍微提高了点,就算手机在各种性能跑分软件面前分数遥遥领先,还是感觉无论有多大的内存空间都远远不够用.相信每个使用 Android 系统的用户都有过以上类似经历,确实,Android
利用 Chrome Dev Tools 进行页面性能分析的步骤说明(前端性能优化)

背景我们经常使用 Chrome Dev Tools 来开发调试,但是很少知道怎么利用它来分析页面性能,这篇文章,我将详细说明怎样利用 Chrome Dev Tools 进行页面性能分析及性能报告数据如何解读. 分析面板介绍上图是 Chrome Dev Tools 的一个截图,其中,我认为能用于进行页面性能快速分析的主要是图中圈出来的几个模块功能,这里简单介绍一下: Network : 页面中各种资源请求的情况,这里能看到资源的名称.状态.使用的协议(http1/http2/quic...).
vue大数据表格卡顿问题的完美解决方案

前言 vue渲染小数据挺快,大数据vue开始出现卡顿现象,本文讲给大家详细介绍关于vue大数据表格卡顿问题的解决方法点我在线体验Demo(请用电脑查看) 亲测苹果电脑,chrome浏览器无卡顿现象,其它浏览器并未测试,如遇到卡顿请备注系统和浏览器,方便我后续优化,谢谢先看一下效果,一共1000 X 100 = 10W个单元格基本感受不到卡顿,而且每个单元格点击可以编辑,支持固定头和固定列项目源代码地址 Github (本地下载) 解决问题核心点:横向滚动加载,竖向滚动加载项目背景笔者最
Android 优化之卡顿优化的实现

Android 系统每隔 16ms 会发出 VSYNC 信号重绘界面(Activity).之所以是 16ms,是因为 Android 设定的刷新率是 60FPS(Frame Per Second),也就是每秒 60 帧的刷新率,约合 16ms 刷新一次. 这就意味着,我们需要在 16ms 内完成下一次要刷新的界面的相关运算,以便界面刷新更新. 假设我们更新屏幕的背景图片需要 24ms 来做这次运算,当系统在第一个 16ms 时刷新界面,由于运算还没有结束,无法绘出图片.当系统隔 16ms 再发一
Android高级开发之性能优化典范

本章介绍android高级开发中,对于性能方面的处理.主要包括电量,视图,内存三个性能方面的知识点. 1.视图性能 (1)Overdraw简介 Overdraw就是过度绘制,是指在一帧的时间内(16.67ms)像素被绘制了多次,理论上一个像素每次只绘制一次是最优的,但是由于重叠的布局导致一些像素会被多次绘制,而每次绘制都会对应到CPU的一组绘图命令和GPU的一些操作,当这个操作耗时超过16.67ms时,就会出现掉帧现象,表现为应用卡顿,所以对重叠不可见元素的重复绘制会产生额外的开销,需要尽量减
iOS性能优化教程之页面加载速率详解

前言我认为在编码过程中时刻注意性能影响是有必要的,但凡事都有个度,不能为了性能耽误了开发进度.在时间紧急的情况下我们往往采用"quick and dirty"的方案来快速出成果,后面再迭代优化,即所谓的敏捷开发.与之相对应的是传统软件开发中的瀑布流开发流程. 卡顿产生的原因在 iOS 系统中,图像内容展示到屏幕的过程需要 CPU 和 GPU 共同参与.CPU 负责计算显示内容,比如视图的创建.布局计算.图片解码.文本绘制等.随后 CPU 会将计算好的内容提交到 GPU 去,由 GP
iOS开发教程之常见的性能优化技巧

前言性能问题的主要原因是什么,原因有相同的,也有不同的,但归根到底,不外乎内存使用.代码效率.合适的策略逻辑.代码质量.安装包体积这一类问题. 但从用户体验的角度去思考,当我们置身处地得把自己当做用户去玩一款应用时候,那么都会在意什么呢?假如正在玩一款手游,首先一定不希望玩着玩着突然闪退,然后就是不希望卡顿,其次就是耗电和耗流量不希望太严重,最后就是安装包希望能小一点.简单归类如下: 快:使用时避免出现卡顿,响应速度快,减少用户等待的时间,满足用户期望. 稳:不要在用户使用过程中崩溃和无响应.
mpvue性能优化实战技巧(小结)

最近一直在折腾mpvue写的微信小程序的性能优化,分享下实战的过程. 先上个优化前后的图: 可以看到打包后的代码量从813KB减少到387KB,Audits体验评分从B到A,效果还是比较明显的.其实这个指标说明不了什么,而且轻易就可以做到,更重要的是优化小程序运行过程中的卡顿感,请耐心往下看. 常规优化常规的Web端优化方法在小程序中也是适用的,而且不可忽视. 一.压缩图片这一步最简单,但是容易被忽视.在tiny上在线压缩,然后下载替换即可. 我这项目的压缩率高达72%,可以说打包后的代码从

CSS3 动画卡顿性能优化的完美解决方案

相关推荐

随机推荐