我知道这个问题的答案是非常特定于浏览器(甚至浏览器版本)的，但我希望可能有一些普遍适用的规则或行为。
我知道我的 JavaScript 在 requestAnimationFrame 回调中的执行时间会减慢调用速度。但是我的代码影响但不一定控制的其他浏览器事件呢？在随后调用 requestAnimationFrame 回调之前，由我的 DOM 更改引起的所有回流、布局和绘制事件是否同步发生？或者是否有可能在之前更改的像素稳定在屏幕上之前调用下一个回调？
最佳答案
通常，浏览器需要做的所有事情，重绘，处理 setTimeout 和 setInterval 都作为一个事件放在事件队列中并一个一个地执行。
requestAnimationFrame 是一种特殊情况，因为它会同步到监视器上的 VBLANK 间隙，这意味着当发生 VBLANK 时将调用回调。
正如 freakish 在他的回答中所说，Javascript 是单线程的，因此是事件队列，但在这种情况下，浏览器将强制事件向前(在当前队列之前)。
在回调中发生的事情是，当前绘制到 Canvas 上的所有内容都被“blit”到浏览器的位图(您在屏幕上看到的)，然后继续执行该功能。无论其他事件的结果是什么，此时也会更新(即使它们正在进行中——在内部，一个元素被处理成它自己的位图，然后作为 Canvas 元素 IIRC 绘制到屏幕上)。
即使回调发生在它应该发生的时间并不意味着例如在回调函数本身的调用之间不能发生绘画事件。这当然会影响性能。
接下来是从第 0 帧到第 1 帧的时间预算，通常约为 16.7 毫秒(@ 60Hz)。如果您的任务未在此预算内完成，则不会发生任何事情，但是当您调用 requestAnimationFrame 时，它不会回调，直到下一个 VBLANK 发生(“跳过心跳”)，您会注意到这是动画(正如您将在 setTimeout/setInternval 中看到的那样，因为它们不与 VBLANK 同步，并且会不时地在更新之间掉落，导致抖动 - 这是 requestAnimationFrame 与其一起提供的主要原因更底层的构造，使其本身具有更高的性能)。
requestAnimatimationFrame 回调率降低到一半(在浏览器中似乎在浏览器中似乎是一致的)(或者如果有硬件限制或在电池上运行)。不同之处在于，现在事件不是每 ~16.7 毫秒强制执行一次，而是在 ~33.4 毫秒执行一次，其他事件像以前一样执行(重绘等)(不确定 vendor 是否通常采用事件队列减速).
关于javascript - 哪些浏览器内部操作会阻止 requestAnimationFrame 被调用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17179931/