使用requestAnimationFrame实现js动画性能好。先给大家简单介绍下requestAnimationFrame比起setTimeout、setInterval有哪些优势？

示例一：

requestAnimationFrame 比起 setTimeout、setInterval的优势主要有两点： 1、requestAnimationFrame 会把每一帧中的所有DOM操作集中起来，在一次重绘或回流中就完成，并且重绘或回流的时间间隔紧紧跟随浏览器的刷新频率，一般来说，这个频率为每秒60帧。 2、在隐藏或不可见的元素中，requestAnimationFrame将不会进行重绘或回流，这当然就意味着更少的的cpu，gpu和内存使用量。 像setTimeout、setInterval一样，requestAnimationFrame是一个全局函数。调用requestAnimationFrame后，它会要求浏览器根据自己的频率进行一次重绘，它接收一个回调函数作为参数，在即将开始的浏览器重绘时，会调用这个函数，并会给这个函数传入调用回调函数时的时间作为参数。由于requestAnimationFrame的功效只是一次性的，所以若想达到动画效果，则必须连续不断的调用requestAnimationFrame，就像我们使用setTimeout来实现动画所做的那样。requestAnimationFrame函数会返回一个资源标识符，可以把它作为参数传入cancelAnimationFrame函数来取消requestAnimationFrame的回调。怎么样，是不是也跟setTimeout的clearTimeout很相似啊。 所以，可以这么说，requestAnimationFrame就是一个性能优化版、专为动画量身打造的setTimeout，不同的是requestAnimationFrame不是自己指定回调函数运行的时间，而是跟着浏览器内建的刷新频率来执行回调，这当然就能达到浏览器所能实现动画的最佳效果了。 目前，各个支持requestAnimationFrame的浏览器有些还是自己的私有实现，所以必须加前缀，对于不支持requestAnimationFrame的浏览器，我们只能使用setTimeout，因为两者的使用方式几近相同，所以这两者的兼容并不难。对于支持requestAnimationFrame的浏览器，我们使用requestAnimationFrame，而不支持的我们优雅降级使用传统的setTimeout。把它们封装一下，就能得到一个统一兼容各大浏览器的API了。 代码可以到这里来查看：

这样子我们就能在所有浏览器上使用requestAnimationFrame和cancelAnimationFrame了。 下面举个简单的例子来说明怎么运用requestAnimationFrame进行动画，下面的代码会将id为demo的div以动画的形式向右移动到300px

示例二：

一直以来，JavaScript的动画都是通过定时器和间隔来实现的。虽然使用CSS transitions 和 animations使Web开发实现动画更加方便，但多年来以JavaScript为基础来实现动画却很少有所改变。直到Firefox 4的发布，才带来了第一种对JavaScript动画的改善的方法。但要充分认识改善，这有利于帮助我们了解web动画是如何演变改进的。 定时器Timer 用于创建动画的第一个模式是使用链式setTimeout()调用。在Netscape 3′s hayday的很长一段时期，开发者都记得一种在网络上随处可见的固定式最新行情状态栏，通常它类似于这样:

如果你想在浏览器中测试这段代码，你可以新建一个 标签用来模拟window.status，例如：newsticker example 这种让人烦恼的web模式，后来遭到对window.status禁用的抵抗，但随着Explorer 4和Netscape 4的发布，浏览器第一次给开发者更多对页面元素的控制权限，这种技术再次出现。这样就出现了使用javascript动态改变元素大小、位置、颜色等的一种全新动画模式。例如，下面就是一个将div宽度变化成100%的动画（类似于进度条）:

尽管动画在页面上的地方不同，但基本原理却是一样的：做出改变，用setTimeout()间隔使页面更新，然后setTimeout又执行下一次变化，这个过程反复执行，直到动画完成（见进度条动画），早期的状态栏动画是相同的技术，只是动画不一样而已。 间隔动画Intervals 随着成功将动画引入web，新的探索开始了。一个动画已经无法满足了，现在需要多个动画。首次尝试为每个动画创建多个动画循环，在早期的浏览器中使用setTimeout()来创建多个动画是有点复杂的，所以开发商开始使用setInterval()一创建单一的动画循环，来管理页面上所有的动画，一个使用wetInterval()的基本动画像这样:

创建一个小动画库，updateAnimations（）方法将每一个动画(同时看到一个新闻股票和进度条在一起运行)循环执行并进行适当的改变。如果没有动画需要更新，该方法可以退出而不做任何事情，甚至停止动画循环，直到有更多的动画更新做好准备。 动画问题比较棘手的问题是延迟应该为多少。间隔一方面必须足够短，从而使不同的动画都能流畅的进行，别一方面还要足够长，使得浏览器可以完成渲染。大多数浏览器的刷新频率为60HZ，即每秒60次刷新，大多数浏览器的刷新频率都不会比这个更频繁，因为他们知道，最终用户是得不到更好的体验的。 鉴于此，为流畅动画的最佳时间间隔为1000毫秒/ 60，约17ms。在这个频率你会看到流畅的动画，那是因为你最大的接近了浏览器能达到的频率。跟以前的动画相比，你会发现17ms间隔的动画更加平滑，也更快（因为动画更新更频繁，没有做其他任何修改的情况下），多个动画可能需要节流，以免17ms的动画完成得太快。 问题 即使使用setInterval()为基础的动画循环比多套使用setTimeout()的动画循环高效，这里还是存在问题。无论是setInterval()还是setTimeout()都无法达到精确，这个延迟即你指定的第二个参数仅仅表示何时代码会添加到浏览器的可能被执行的UI线程队列中。如果队列中有其他工作在此之前，那代码将会等到他完成才会执行。简而言之，毫秒级的延迟不是表示何时代码会执行，而是表示何时代码会添加进队列。如果UI线程处于繁忙状态或在处理用户动作，那么代码将不会被马上执行。 平滑动画的关键是理解下一帧何时被执行，直到现在都没有一个方法来保证下一帧将会在浏览器中被绘制。随着的日益流行和新的基于浏览器的游戏的出现，开发商对setInterval()和setTimeout()的不精准越来越感到失望。 浏览器的计时器分辨率加剧了这个问题，计时器对毫秒不精准，这里有一些常见的计时器分辨率：

Internet Explorer 8 and earlier 15.625ms Internet Explorer 9 and later 4ms. Firefox and Safari ~10ms. Chrome has a timer 4ms.

mozRequestAnimationFrame(updateProgress); 由于mozRequestAnimationFrame()只运行给定的函数一次，你需要在下一次UI动画的时候再次调用它。你也需要相同的方法来管理何时停止调用。很酷，是非常流畅的动画增强的实例。 因此，mozRequestAnimationFrame()解决了浏览器不知道Javascript动画正在执行和不知道多少才是合适的间隔的问题，但对于不知道何时你的代码才被真正执行，也是由这个方案来解决的。 传递给mozRequestAnimationFrame()的函数实际是一个下一次重绘何时发生的的时间码（以毫秒为单位自1970年1月1日计算）。这是很重要的一点：mozRequestAnimationFrame()实际上列表出将要重绘的点并可以告诉你他们所处的时间。这样你就能够决定怎样更好的来调整你的动画。 为了得到上次重绘过去的时间，你可以查询mozAnimationStartTime，其中包含了过去重绘的时间代码。减去传递回调时的这个值可以计算出下一次重绘到屏幕时所用的时间。使用这些值的典型模式如下:

关键是第一次不是通过callback调用时，mozAnimationStartTime是到mozRequestAnimationFrame()经过的时间。如果是在回调函数中，mozAnimationStartTime是通过参数传递进来的时间代码平均值。 webkitRequestAnimationFrame 在很多人热忠于chrome时，随即创建了webkitRequestAnimationFrame()方法。这个版本与firefox的版本在两方面有着细微的差别。一方面，它不通过回调函数传递时间代码，你将无法知道下次重绘何时发生，另一方面，它添加了第二个可选参数来确定哪一个DOM元素发生改变。因此，如果你知道重绘发生在页面哪个部分的元素内，你可以限制重绘发生的区域。 应该不会感到惊讶，有没有相应的mozAnimationStartTime，因为如果没有下一个重绘的时间信息不是很有益。有，只是webkitCancelAnimationFrame()取消了之前计划的重绘。 如果你不需要精确的时间差异，你可以用下面的方式来创建一个用于Firefox4和chrome10+的动画:

这种模式使用可用的方法来创建以花费多少时间为理念的循环动画。Firefox使用时间代码信息是有用的，而Chrome默认为欠精准的时间对象。当用这种模式的时候，时间的差异给你一种多少时间过去了的想法，但不会告诉你Chrome的下一次重绘出现在何时。不过这比只有多少时间过去了的模糊概念要好些。 总结 mozRequestAnimationFrame()方法的介绍为推动Javascript 动画及web的历史发展有着非常重要的作用。如前所述，JavaScript动画的态几乎和JavaScript的初期一样。随着浏览器逐渐推出CSS transitions 和 animations，很高兴看到基于JavaScript的动画的关注，因为这些在基于的游戏领域将变得更重要和更与CUP联系紧密。知道Javascript何时尝试动画，允许浏览器做更多的优化处理，包括在tab处于后台或移动设备电量过低时停止进程。 该requestAnimationFrame（）API现在正由W3C起草一个新议案，并正由Mozilla和Google努力使之成为Web大舞台的一部分。很高兴能看到这两大集团这么迅速的兼容（可能不完全）实现。 RequestAnimFrame使用 对于一个侦中对DOM的所有操作，只进行一次Layout和Paint。 如果发生动画的元素被隐藏了，那么就不再去Paint。

以上通过两段代码示例详解说明了使用requestAnimationFrame实现js动画性能好，希望大家喜欢。