javascript - JS 使用 setTimeout 时无法准确计时自己的执行

Question

请注意:链接到的问题不能回答我的问题。 Bergi 的回答是我所问问题的正确答案。

首先，请看一下这个简单的倒计时器:

http://jsfiddle.net/49tH7/ (永久代码见下文)

确保打开控制台，以便您可以看到倒计时。我使用最新版本的 chrome 进行了测试。

代码说明

注意我们调用计时器的方式:

timer = CountdownTimer(5000, 5, function(tickNum) { console.log(tickNum) });
timer.start();

我们传递计时器倒计时所需的总时间(5000 毫秒)、应完成的总滴答数(在本例中为每秒 5 - 1 次)以及每次滴答时调用的回调函数。回调函数传递了刻度数，在本例中，它只是将其打印出来。当代码执行完毕后，将调用 onFinish() 方法，该方法仅打印出计时器刚刚运行的总毫秒数。理论上，这应该始终非常接近传递给 CountdownTimer 构造函数的第一个参数，在本例中为 5000。

滴答之间的时间是自适应的，考虑到执行回调所花费的时间。如果回调代码平均缓慢且复杂，optimalPauseTime() 方法将检测到这一点，并开始调整滴答之间的时间，以便计时器仍然在第一个参数中指定的总时间内完成到倒计时器。因此，计时器的总运行时间和滴答总数是固定量，但滴答之间的时间是动态且可变的。

奇怪的行为和我的问题

要了解这篇文章的动机，请将 fiddle 的刻度数增加到 1000，然后打开手机的秒表:

timer = CountdownTimer(5000, 1000, function(tickNum) { console.log(tickNum) });
timer.start();

按下运行键后立即启动秒表，并在看到控制台输出结束后立即停止。显然，这是一个粗略的估计，可能会有一秒钟的偏差，但足以了解发生了什么。日志的最终输出如下所示:

999 (index):54
1000 (index):54
5004 

我的秒表读数为 8.5 秒。我进行了多次测试，结果相似。

问题 1 JavaScript 代码声称只花了 5004 毫秒运行，而实际上比这多了几秒，这怎么可能？

问题 2 要查看问题的夸大版本并观察 CPU 的飙升，请将刻度线调至 2000，然后再次运行。在这种情况下，我的秒表运行了大约 25 秒，最终输出的数字是 8727。所以现在代码能够检测到它运行得更慢，但它仍然低估了这种缓慢程度。到底发生了什么可以解释这一切？

JSFiddle 代码

function CountdownTimer(totalMs, totalTicks, tickCb) {

    var ret = {}, startTime, ticksCompleted;

    function tick() {
      if (ticksCompleted == totalTicks) { onFinish(); return; }
      ticksCompleted++;
      tickCb(ticksCompleted);
      setTimeout(function() {tick()}, optimalPauseTime());
    }

    function optimalPauseTime() {
      var timeElapsed = new Date() - startTime;
      var avgTickTimeSoFar = timeElapsed / ticksCompleted;
      var ticksRemaining = totalTicks - ticksCompleted;
      var timeRemaining = totalMs - timeElapsed;
      return timeRemaining / ticksRemaining;
    }

    function start() { 
        startTime = new Date(); 
        ticksCompleted = 0;
        tick(); 
    }

    function onFinish() {
      console.log(new Date() - startTime);
    }

    ret.start = start;
    return ret;
}

timer = CountdownTimer(5000, 5, function(tickNum) { console.log(tickNum) });
timer.start();

Answer 1

How is it possible that the javascript code is claiming that it took only 5004 ms to run, when it actually took a few seconds longer than that?

我无法重现。也许你的秒表(或触发它的过程？)不准确； new Date 通常效果很好。

也许您也只是遇到了控制台延迟，它并没有不断更新以流畅地运行页面。在控制台中显示大量消息可能会成为瓶颈(将它们写入控制台缓冲区不应该)。

To see an exaggerated version of the problem and watch your CPU shoot up, crank the ticks up to 2000 and run it again. In this case, it took about 25 seconds to run by my stopwatch, and the final number output was 8727. So now the code is able to detect that its running more slowly, but it is still underestimating that slowness a lot. What is going on that explains all this?

浏览器中实现了最小超时。 5 秒内有 2000 个滴答，预计每 2.5 毫秒一次滴答，这太低了。浏览器无法这么快地安排刻度。

此外，onFinish() 调用始终会再推迟一次，即通常在实际结束后大约 4 毫秒。

此外，您的 optimalPauseTime 并不以精确为目标，而是以平均分配超时为目标。当它迟到并试图 catch 时，它不会立即 catch - 而是将这种追赶分配给剩余的滴答声。相反，你可能会做类似的事情

function tick() {
  ticksCompleted++;
  tickCb(ticksCompleted);
  if (ticksCompleted == totalTicks) {
    onFinish();
  } else {
    var pause = optimalPauseTime();
    if (pause <= 0)
      tick();
    else
      setTimeout(tick, pause);
  }
}

function optimalPauseTime() {
  var timeElapsed = new Date() - startTime;
  var nextTickRatio = (ticksCompleted + 1) / totalTicks;
  var expectedNextTime = totalMs * nextTickRatio;
  return expectedNextTime - timeElapsed;
}

( updated demo )