简单地讲，requestAnimationFrame函数更适合在浏览器上面做复杂的动画。比用定时器效率高。
废话如下：
现代的WEB世界(2020年)，网页上各种各样的内容丰富多彩。虽然css也能完成很多简单的动画，但是仍然有一些复杂的动画animation需求需要javascript处理。之前，我简单地理解，浏览器已经有定时器函数setTimeout()和setInterval(),就足够做出复杂的动画形式。原来，不是这样的。
这段时间在做一个运行在浏览器上的红白机模拟器，参考开源代码，发现用的是requestAnimationFrame()函数。于是，查了一些资料，涨了知识。
首先，使用定时器SetTimeout和setInterval做动画有两个大缺点。
- 受有限的资源，或者糟糕的cpu密集的业务代码的影响。浏览器并不严格按照定时器函数中的时间间隔参数来调度定时回调函数。比如50ms，有时会快，有时会慢。这样，动画效果的帧与帧之间的画面就不会那么流畅了。
- 频繁的调用计时器函数setTimeout或setInterval，可能导致浏览器假死。浏览器竭尽全力的处理一些跟动画无关的代码，比如文档流的不断重排。这样，用户的界面根本没有获得重新渲染的机会。特别在手机浏览器，由于手机的环境比较特殊。手机的电池可以不够，网络不好，都可能影响web页面的文档重排（page reflow）的效率。
为什么用requestAnimationFrame
- 针对定时器的缺点1，浏览器的实现保证requestAnimationFrame设定的回调函数会严格定时执行。当然是在web页是活跃状态，即不是在后台运行。等下会讲到后台执行时的情况。一般浏览器调用requestAnimationFrame设定的回调函数的频率是每秒60次。不同浏览器的实现有不变。
-
当web页面被放入后台运行时，浏览器会大辐降低requestAnimationFrame设置的回调函数调用频率。低至每秒两次，甚至暂停。这样，又能节省相当多的资源。比如手机上珍贵的电池资源。非常容易理解，web页面不可见的时候，还继续渲染画面是完全没有意义的。
需要注意的地方
既然requestAnimationFrame的调用频率因浏览器而异，另外页面在后台时又可能会暂停。所以，生成动画的代码不能预设回调函数以某一个固定的频率执行。解决这个问题，requestAnimationFrame的回调函数会传入一个时间戳参数，
下面是官方文档对传入回调函数的时间参数的解释，给了一个高精度的时间戳，单位是毫秒。嗯，对于浏览器来说，如果能精确到毫秒的话，算得上高精度的时间戳了。
The callback function is passed one single argument, a DOMHighResTimeStamp similar to the one returned by performance.now(), indicating the point in time when requestAnimationFrame() starts to execute callback functions