移动swiper中动画卡顿，通过requestAnimationFrame写向下的动画

版权声明：仅供个人学习使用，如有雷同，纯属巧合。 https://blog.csdn.net/erdfty/article/details/84134254

当手机网页使用swiper的时候，在css中写入动画的时候有些时候浏览页面会进行卡顿，这个时候你就需要手写动画了，以下为参考的一些的案例，大家可以用来参考

[code]setT();
var dataSet = 0, dataStop = 0.35, dataSetT = 7;

function setT(){
$(".jiantou").css({"margin-bottom" : dataSet+"px" });
dataStop =  dataSet >= dataSetT ? -dataStop : dataSet <= -dataSetT ? -dataStop : dataStop;
dataSet += dataStop;
requestAnimationFrame(setT);
}

requestAnimationFrame

与setTimeout相比，requestAnimationFrame最大的优势是由系统来决定回调函数的执行时机。具体一点讲，如果屏幕刷新率是60Hz,那么回调函数就每16.7ms被执行一次，如果刷新率是75Hz，那么这个时间间隔就变成了1000/75=13.3ms，换句话说就是，requestAnimationFrame的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，也不会导致动画出现卡顿的问题。

这个API的调用很简单，如下所示：

[code]var progress = 0;
//回调函数
function render() {
progress += 1; //修改图像的位置

if (progress < 100) {
//在动画没有结束前，递归渲染
window.requestAnimationFrame(render);
}
}

//第一帧渲染
window.requestAnimationFrame(render);

除此之外，requestAnimationFrame还有以下两个优势：

• CPU节能：使用setTimeout实现的动画，当页面被隐藏或最小化时，setTimeout 仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，完全是浪费CPU资源。而requestAnimationFrame则完全不同，当页面处理未激活的状态下，该页面的屏幕刷新任务也会被系统暂停，因此跟着系统步伐走的requestAnimationFrame也会停止渲染，当页面被激活时，动画就从上次停留的地方继续执行，有效节省了CPU开销。

• 函数节流：在高频率事件(resize,scroll等)中，为了防止在一个刷新间隔内发生多次函数执行，使用requestAnimationFrame可保证每个刷新间隔内，函数只被执行一次，这样既能保证流畅性，也能更好的节省函数执行的开销。一个刷新间隔内函数执行多次时没有意义的，因为显示器每16.7ms刷新一次，多次绘制并不会在屏幕上体现出来。

 

阅读更多