javascript Safari 中的断断续续滚动
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/24156709/
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
Choppy scrolling in Safari
提问by Dominik Hadl
I have a problem with my micro website. When I scroll, it's nice and smooth in all browsers except Safari. When I do scroll in Safari, the content div jumps or moves frequently (it should stay in place) and makes the scrolling look choppy. Do you have any idea what could be wrong?
我的微网站有问题。当我滚动时，它在除 Safari 之外的所有浏览器中都非常流畅。当我在 Safari 中滚动时，内容 div 经常跳跃或移动（它应该保持原位）并使滚动看起来不连贯。你知道什么可能是错的吗？
This is the website:
http://beta.dynamicdust.com
这是网站：http:
//beta.dynamicdust.com
采纳答案by Hyman
I took a look and did see the "choppy" scrolling you mentioned (looking at it more, it was hit or miss - sometimes it was smooth, other times it was VERY choppy).
我看了一眼，确实看到了您提到的“断断续续”滚动条（再看一遍，它被击中或未命中 - 有时它很平滑，有时它非常不稳定）。
It seems you've got some performance issues with your parallaxcallback on Safari (though it wouldn't surprise me if it's some buggy implementation with Safari...)
您parallax在 Safari上的回调似乎存在一些性能问题（尽管如果 Safari 的实现存在一些错误，我也不会感到惊讶...）
One thing I would recommend is taking a look at requestAnimationFramefor webkit. For a test, I wrapped the logic to update the offsets in a raf(and cached the window.pageYOffsetvalue) and it seemed smoother on my end.
我建议的一件事是查看requestAnimationFramewebkit。对于测试，我将更新偏移量的逻辑封装在 a 中raf（并缓存了该window.pageYOffset值），结果看起来更流畅。
function parallax(e) {
window.webkitRequestAnimationFrame(function() {
var offset = window.pageYOffset;
a.style.top = (offset / 2) + "px";
b.style.top = (offset / 2) + "px";
textbox.style.top =- (offset * 0.7) + "px";
textbox2.style.top =- (offset * 0.7) + "px";
});
}
To be honest, you could probably use raffor all browsers (if they support it).
老实说，您可能raf适用于所有浏览器（如果它们支持）。
Another trick people use when animating elements is to accelerate the layer that the element you are animating is on. There are a few ways to do this, but the easiest is to use -webkit-transitionand set translateZ(0). It wouldn't hurt to add the two additional lines as well:
人们在为元素设置动画时使用的另一个技巧是加速您正在设置动画的元素所在的层。有几种方法可以做到这一点，但最简单的是使用-webkit-transition和设置translateZ(0)。添加另外两行也没有什么坏处：
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
Also, I noticed that some elements you offset (using style) are position: relative- Personally, I'd say that any element that's to be animated should be position: absolute. This will remove the element from the DOM, and offsetting it won't cause reflows to surrounding elements (which may contribute to your choppiness).
此外，我注意到您偏移（使用style）的某些元素是position: relative- 就我个人而言，我会说任何要动画的元素都应该是position: absolute. 这将从 DOM 中删除元素，并且抵消它不会导致回流到周围的元素（这可能会导致您的不稳定）。
Edit - one other thing I noticed is that "choppiness/weirdness" happens when you encounter rubberbanding on safari (my guess are the negative values). That might be something you'll want to look at as well.
编辑 - 我注意到的另一件事是，当您在 safari 中遇到橡皮筋时会发生“断断续续/怪异”（我的猜测是负值）。这可能也是您想要查看的内容。
Good luck!
祝你好运！
回答by Kevin Flansburg
I haven't checked to see how my answer compares to Hyman's, but I think the problem is that Safari attempts to be very power efficient. As a result, it is hesitant to enable hardware acceleration unless it needs to. A common trick that people use to force hardware acceleration is to place
-webkit-transform: translate3d(0, 0, 0);into the css for the divs which are moving. I tried it with the content class and it seemed a little better. You might try applying it to the other layers as well.
我还没有检查过我的答案与 Hyman 的相比如何，但我认为问题在于 Safari 试图非常节能。因此，除非需要，否则会犹豫是否启用硬件加速。人们用来强制硬件加速的一个常见技巧
-webkit-transform: translate3d(0, 0, 0);是将移动的 div 放入 css 中。我在内容类中尝试了它，它似乎好一点。您也可以尝试将其应用于其他图层。
EDIT: I applied it to the left and right text holder divs as well, and the page seems just as smooth as Chrome now.
编辑：我也将它应用于左右文本持有人 div，现在页面看起来和 Chrome 一样流畅。
回答by Christopher Davies
Just jotting this down, as I came across this today with an overflow auto element:
只是记下来，因为我今天遇到了一个溢出自动元素：
The solution was to add this rule to whatever element the scrollbar shows up on:
解决方案是将此规则添加到滚动条显示的任何元素中：
-webkit-overflow-scrolling: touch;
-webkit-overflow-scrolling: touch;
More detail can be found here:
可以在此处找到更多详细信息：
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
回答by borisdiakur
Elements with heavy transitions on hover and active state can result in rendering issues.
在悬停和活动状态上具有大量过渡的元素可能会导致渲染问题。
In our case we had box-shadow transitions on some elements that were applied on hover. When the user scrolled the page and swiped the effected element, the transition got triggered. The browser then had to do the hard work of rendering the transition while scrolling.
在我们的例子中，我们在悬停时应用的一些元素上有框阴影过渡。当用户滚动页面并滑动受影响的元素时，转换被触发。然后浏览器不得不在滚动时渲染过渡。
