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