译者：伊一
requestAnimationFrame傻瓜调度
有些人对requestAnimationFrame回调的调度很好奇，那么请看这里：
所有的rAF回调总是会在工作中的同一帧或下一帧中运行
在事件处理程序中排队的所有rAFs都会在_同一帧_中执行。 在一个rAF中排队的rAFs都会在_下一帧_中执行。 所有排队的rAFs都_将_会在准备的帧中执行。
假设这里有5个回调在排队等候，每个将会耗时100ms左右。浏览器不会把它们分发到众多帧中，而是在准备的帧中执行所有回调，即使会花费500ms。这意味着会有很明显的卡顿。
你可能会问，“为什么会在一个帧中有5个animationFrame回调请求？”这种情况偶尔会发生，当你做下面2个非常合理的事情时：1)在一个rAF的结尾你请求了一个新的回调。2)你从一个输入处理程序中请求rAF回调。结果，你在每一帧的工作量会变成两倍/三倍。
你请求的每个rAF都将会运行
rAFs并不会因为执行时间过长而被扼杀。
是否聚合rAFs完全取决于你自己。所以：如果在同一帧中触发了多次“相同的”回调，那么你必须管理这个调度/聚合。
即便如此，Chrome（至少）试图有所帮助。如果rAFs霸占了主线程，浏览器将会开始制约输入事件，希望如此可以清理竞争。
那么现在，这两幅图表（尽管只是略微相关）可能说明了一帧中事件的生命周期：
一帧内的过程(主线程版本)
一帧中的事件分发
想知道更多的实现细节，Sami在BlinkOn 3上关于调度的演讲值得一看，你也可以在ds-hwang的Chromium浏览器文档中查看_Scheduler Overhaul_的资源.