为什么 jQuery 不使用 requestAnimationFrame？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7999680/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why doesn't jQuery use requestAnimationFrame?
提问by Randomblue
Some browsers support requestAnimationFrame, so why not use it? After all, it's been supported since Google Chrome 10. Despite that, jQuery does not seem to be using it. I've found a bug reportabout it, but no real explanation was given? I'm sure the jQuery people have their reasons, though.
有些浏览器支持requestAnimationFrame，为什么不使用它呢？毕竟，它从 Google Chrome 10开始就得到支持。尽管如此，jQuery似乎并没有使用它。我找到了一个关于它的错误报告，但没有给出真正的解释？不过，我相信 jQuery 人有他们的理由。
Why wouldn't they use this awesome API?
他们为什么不使用这个很棒的 API？
回答by Mitar
In ticket #9381you can read why they stopped using requestionAnimationFrameafter some time.
在票号 #9381 中，您可以了解为什么他们requestionAnimationFrame在一段时间后停止使用。
To summarize, problems were that animations didn't run (browsers try to reduce CPU load) when window didn't have focus, which is OK if the window is hidden, but not if it is visible, just out of the focus. Furthermore, animation queues piled up and after window regained focus, things went berserk. This would require ugly changes in the code and/or changes how people add things to the animation queue. So it was decided that support is removed until there is some better way to do this.
总而言之，问题是当窗口没有焦点时动画没有运行（浏览器试图减少 CPU 负载），如果窗口是隐藏的，这是可以的，但如果它是可见的，就不是焦点。此外，动画队列堆积如山，在窗口重新获得焦点后，事情变得疯狂。这将需要对代码进行丑陋的更改和/或更改人们向动画队列添加内容的方式。因此决定移除支持，直到有更好的方法来做到这一点。
回答by Chris Moschini
Given the other answers and objections here I wanted to test this out on a simple slideshow animation:
鉴于这里的其他答案和反对意见，我想在一个简单的幻灯片动画上对此进行测试：
As of 2013 the objections in other answers here no longer appear to be significant. I've added
截至 2013 年，此处其他答案中的反对意见似乎不再重要。我已经添加
to my existing animation code, and verified it's switching on and affecting the fade animations in use. It works reliably, even in background windows, in Chrome 30, IE 11, and FF 24. Testing Android 2.3, it appears to use the polyfill and work as expected.
到我现有的动画代码，并验证它正在打开并影响正在使用的淡入淡出动画。它在 Chrome 30、IE 11 和 FF 24 中运行可靠，即使在后台窗口中也是如此。测试 Android 2.3，它似乎使用 polyfill 并按预期工作。
jQuery 3
jQuery 3
jQuery 3.0 integrates requestAnimationFrame. Basically, jQuery could handle it fine, but some users would call .setInterval(function() { tag.animate(, screwing it up. Thus the punt to major version release. jQuery 3 does not and will never support IE8 and below, so if you have IE8 users, stick with jQuery 1.x.
jQuery 3.0 集成了 requestAnimationFrame。基本上，jQuery 可以很好地处理它，但有些用户会调用.setInterval(function() { tag.animate(，把它搞砸了。因此，主要版本发布的平底船。jQuery 3 不支持也永远不会支持 IE8 及以下版本，因此如果您有 IE8 用户，请坚持使用 jQuery 1.x。
CSS Transitions
CSS 转换
In my testing, the CPU/battery-saving claims of requestAnimationFrameare false promises. I see high CPU usage with it on, for example, long-fades. What does save CPU/battery is CSS Transitions, probably because the browser, especially mobile browsers, get to make much stronger assumptions about what you intend and what else is being asked of them, and native code is still faster than Javascript+DOM.
在我的测试中， 的 CPU/电池节省声称requestAnimationFrame是虚假承诺。我看到它的 CPU 使用率很高，例如，长淡出。节省 CPU/电池的是CSS Transitions，可能是因为浏览器，尤其是移动浏览器，可以对您的意图和其他要求做出更强有力的假设，并且本机代码仍然比 Javascript+DOM 快。
So if you really want to save CPU/battery, CSS Transitions are for you. IE9 and below can't handle them and there are still plenty of users out there, so consider jquery.transitand their Fallback to animateat the bottom of the page.
所以如果你真的想节省 CPU/电池，CSS Transitions 适合你。IE9 及以下无法处理它们，而且仍有大量用户在那里，因此请考虑在页面底部使用jquery.transit和它们的 Fallback to animate。
回答by jfriend00
In the jQuery source for v1.6.2, I see requestAnimationFramebeing used if it's present. I haven't studied the code in great detail to see that it's being used for everything it could be used for, but it is being used in the animation section of the code instead of a call to setInterval(). Here's the code from 1.6.2:
在 v1.6.2 的 jQuery 源代码中，requestAnimationFrame如果存在，我会看到正在使用。我没有详细研究代码以了解它被用于它可以用于的一切，但它被用于代码的动画部分而不是调用setInterval(). 这是 1.6.2 的代码：
// Start an animation from one number to another
custom: function( from, to, unit ) {
var self = this,
fx = jQuery.fx,
raf;
this.startTime = fxNow || createFxNow();
this.start = from;
this.end = to;
this.unit = unit || this.unit || ( jQuery.cssNumber[ this.prop ] ? "" : "px" );
this.now = this.start;
this.pos = this.state = 0;
function t( gotoEnd ) {
return self.step(gotoEnd);
}
t.elem = this.elem;
if ( t() && jQuery.timers.push(t) && !timerId ) {
// Use requestAnimationFrame instead of setInterval if available
if ( requestAnimationFrame ) {
timerId = true;
raf = function() {
// When timerId gets set to null at any point, this stops
if ( timerId ) {
requestAnimationFrame( raf );
fx.tick();
}
};
requestAnimationFrame( raf );
} else {
timerId = setInterval( fx.tick, fx.interval );
}
}
},
I am not yet using 1.6.4 so I don't know about that version. If it's not in that version, then there must have been some issues so it was removed.
我还没有使用 1.6.4，所以我不知道那个版本。如果它不在那个版本中，那么一定有一些问题，所以它被删除了。
EDIT:
编辑：
If you read this blog post, it sounds like it was pulled out of 1.6.3 and perhaps will be put back in 1.7 and the main reason it was pulled is because it broke some things people were "incorrectly" using the animation queue for (though perhaps that is a matter of opinion).
如果你读过这篇博文，听起来好像它被从 1.6.3 中拉出来了，也许会在 1.7 中放回去，它被撤下的主要原因是因为它打破了人们“错误地”使用动画队列的一些东西（虽然也许这是一个意见问题）。
