RequestAnimationFrame定期加快/降低速度

Question

据我了解，requestAnimationFrame的运行速度应尽可能接近浏览器的帧速率（约60fps）。为了确保确实发生这种情况，我一直在记录每个requestAnimationFrame调用的时间戳，如下所示：

function animate(now){
    console.log(now);
    window.requestAnimationFrame(animate);
}
window.requestAnimationFrame(animate);

Console.log数据显示调用始终在大约0.016674毫秒之间进行，因此表明帧速率为？。60fps（精确到59.9736116108912fps）。

Console.logs（样本数据）：

Timestamp   FPS               (Current - previous) timestamp
------------------------------------------------------------
100.226     59.97361161       0.016674
116.9       59.97361161       0.016674
133.574     59.97361161       0.016674
   .             .               .
   .             .               .
150.248     59.97361161       0.016674
166.922     59.97361161       0.016674
183.596     59.97361161       0.016674
200.27      59.97361161       0.016674

到目前为止，requestAnimationFrame调用是在一致的时间间隔内进行的，并且调用不会滞后/执行得太快。

但是，修改animate（）函数的内容以执行相对更复杂的函数会导致requestAnimationFrame调用不一致。

Console.logs（样本数据）：

Timestamp       FPS               (Current - previous) timestamp
------------------------------------------------------------
7042.73         59.97361161       0.016674
7066.278        42.4664515        0.023548
7082.952        59.97361161       0.016674
7099.626        59.97361161       0.016674
   .                 .                .
   .                 .                .
17104.026       59.97361161       0.016674
17112.84        113.4558657       0.008814
17129.514       59.97361161       0.016674
17146.188       59.97361161       0.016674

从上面的数据样本中可以看出，时间戳差异和帧速率不再稳定，有时发生得太早/太晚，导致帧速率不一致。如果requestAnimationFrame一直被延迟调用，我会假设由于JavaScript的单线程性质，驻留在animate（）函数中的复杂代码执行所需的时间太长，因此导致requestAnimationFrame调用延迟。但是，由于requestAnimationFrame偶尔被调用为时过早，因此似乎并非如此。

我的代码（骨架）：

for (var counter = 0; counter < elements.length; counter ++) //10 elements
{
  //some other code

  animate(element);
}

function animate(element)
{
   // function invocation => performs some complex calculations and animates the element passed in as a parameter

   window.requestAnimationFrame(function() { animate(element) } );
}

从上面的代码片段中可以看出，在初始for循环内，每个元素的requestAnimationFrame被多次调用。每个元素的RequestAnimationFrame调用也旨在无限进行。由于要执行的动画具有很高的时间紧迫性（动画定时在这种情况下非常重要，应该尽可能准确），因此至关重要的是，requestAnimationFrame调用始终以一致的时间间隔发生。理想情况下，这些时间间隔应尽可能接近0.016674（？60fps）。

有关要执行的动画的一些细节（在每个画布元素上）：

我有一个非常特殊的情况，在这种情况下，我需要相对于时间尽可能准确地绘制一个闪烁的动画，即，在指定的时间间隔内，画布颜色必须以一致的速率进行更改。因此，例如，画布颜色需要精确地保持红色0.025秒，然后再将画布颜色设置为蓝色，再保持0.025秒，然后再将画布红色设置为0.025秒，以此类推...（动画应对于每个元素，都可以无限地进行下去）。我当前的方法涉及跟踪动画循环本身中经过的帧数（因此，每个requestAnimationFrame调用都对应于一个帧）。

由于在60Hz监视器上无法达到0.025秒的精确帧长，因此每个“红色/蓝色”画布周期都应“近似”。因此，考虑使用60Hz监视器，创建一个完整的周期，其中画布最初是红色，然后是蓝色，则总共需要3帧（1秒/ 60 = 0.01666667秒* 3帧= 0.05秒=>一个完整的红色/蓝色循环所需的持续时间）。将0.05秒除以2将得到所需的帧长度（即0.025秒），但是由于无法在60Hz监视器上实现，因此可以通过显示2个红色画布帧，然后是一个蓝色帧（由此形成整个3帧周期）。不幸的是，即使考虑到监视器的刷新率，时间也会有所波动，

最后的问题：

1. 您能否弄清楚是什么导致了这种requestAnimationFrame不一致的行为？

2. 是否可以应用任何优化来确保requestAnimationFrame调用以一致的时间间隔执行？

3. 如果使用其他某种功能（例如，将web worker与setInterval（）函数结合使用），是否可以实现更好的计时精度？

Answer 1

requestAnimationFrame 将“尽最大努力”以“一致”的帧速率运行。这并不能保证 60fps；它只是声明它将尽可能快地制作动画。

简而言之，该方法允许您在下一个可用的屏幕重绘上执行代码，从而消除了与用户浏览器和硬件准备同步以更改屏幕的猜测工作。

我们输入一个包含我们希望运行的代码的回调函数，当屏幕准备好接受下一个屏幕重绘时， requestAnimationFrame() 将运行它。

为了保持动画恒定，您必须根据实际增量重新计算回调中的数据，而不是假设恒定的 FPS。

例如：

function moveit(timestamp, el, dist, duration){
    //if browser doesn't support requestAnimationFrame, generate our own timestamp using Date:
    var timestamp = timestamp || new Date().getTime()
    var runtime = timestamp - starttime
    var progress = runtime / duration
    progress = Math.min(progress, 1)
    el.style.left = (dist * progress).toFixed(2) + 'px'
    if (runtime < duration){ // if duration not met yet
        requestAnimationFrame(function(timestamp){ // call requestAnimationFrame again with parameters
            moveit(timestamp, el, dist, duration)
        })
    }
}

requestAnimationFrame(function(timestamp){
    starttime = timestamp || new Date().getTime() //if browser doesn't support requestAnimationFrame, generate our own timestamp using Date
    moveit(timestamp, adiv, 400, 2000) // 400px over 1 second
})