我一直在使用 requestAnimationframe for chrome，想知道它的实际行为如何。
当我加载我的画布并进行绘制时，我得到了稳定的 60FPS。如果我像点击一样使用偏移量滚动并在地图上拖动，FPS 会下降（如预期的那样）......一旦我停止在地图上拖动，FPS 就会再次按预期恢复到稳定的 60fps。
我想知道这是否是为 requestAnimationframe 考虑的。如果我拖动地图直到 FPS 下降，长时间下降到 30 以下，一旦我停止拖动，它就会重新爬升，但这次它达到 30FPS 并且不会更高。似乎浏览器认为 30FPS 可能是最好的选择。
这是由浏览器故意完成的，我一直试图找出是否是这种情况。因为如果我不长时间低于 30fps，它将达到 60fps。
【问题讨论】：
标签： javascript performance-testing
是的，这是浏览器能够做到的。
“它应该如何工作”并不是任何人都可以在这里回答的。
原因很简单，引擎盖下是 100% 特定于浏览器的。
但可以肯定地说，是的，浏览器能够决定何时应该将您锁定为 30Hz 刷新，而不是 60Hz 刷新。
说明为什么会这样：
如果供应商愿意，requestAnimationFrame() 也与页面可见性 API 相关联（对于 Chrome 来说非常正确）。
基本上，如果页面不可见，他们可以将requestAnimationFrame() 更新减慢到每秒几次或完全暂停它们。
鉴于这些知识，完全有可能相信以下两种情况之一正在发生：
他们故意将您的速度限制在 30 fps，因为根据平均性能数据，他们认为您的体验会更稳定
他们故意限制你，但系统中有一些错误（或一些不太宽松的数学）阻止你在海岸清除后回到 60，如果他们 正在使用平均性能数据，那么这可能是问题的一部分。
无论哪种方式，它至少大部分是有意的，唯一未解决的问题是为什么它坚持 30 fps。 事后你有没有让它静置 20 或 30 分钟，然后看看它是否会在任何时候恢复？
【讨论】：
您可以从 Chrome DevTools 运行 Timeframe 分析，以查找导致动画时间变慢的特立独行 JS。
https://developers.google.com/chrome-developer-tools/docs/timeline
RAF 会找到最好的位置来绘制您的更改，而不是最接近的位置。因此，如果 RAF 回调中的 JS 花费了两帧的时间（在 60hz 硬件上每帧大约 16ms），那么您的 FPS 将下降到 30。
来自保罗·爱尔兰，途经鲍里斯
实际上，“它目前的上限为 1000/(16 + N) fps，其中 N 是执行回调所需的毫秒数。如果你的回调需要 1000 毫秒来执行，那么它的上限是 1fps。如果你的回调需要 1ms 执行，你会得到大约 60fps。” （谢谢，鲍里斯）
http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/
【讨论】：