我所发现的是,当您滚动时,右侧的列会导致一些jank(在低端硬件上尤其明显).
在chrome时间轴中,我可以在滚动列时看到一些主要的“更新图层树”.
有什么办法可以弄清楚为什么“更新图层树”是如此漫长,什么CSS属性影响速度最多？
当我点击它 – 只是给我的信息,它运行了多长时间,没有别的.
我在每个li中都有一些CSS,效果不好(例如,过滤器,转换,Box-shadows等)
如果我逐个删除每个SASS文件,它可以提高滚动性能(并且一旦我删除所有的CSS,最终会删除jank),但显然很难指出哪些CSS属性不执行此操作.
我想知道如果我在chrome时间表中缺少可以在这方面有帮助的内容吗？
我试图使用意志变化的CSS属性来促进滚动到不同的层/强制硬件加速 – 但这并没有太大的区别.
此外,我滚动时没有执行JavaScript事件.
限制不到200个项目不是一个选择.
我已经设置了一个例子(我知道它的一个更长的项目列表,但这只是为了演示目的)：
https://github.com/jooj123/jank/blob/master/scroll.html
真正有趣的是,如果我删除overflow-y：scroll; (在.map-search__结果在上面的例子中)滚动变得非常顺利并且jank消失了 – 为什么这么多效果？
这是chrome时间轴(基本上只是长的“更新图层树”部分)：
固定：
Paul’s answer about will-transform is spot on,特别是这个tidbit帮助：
“Add will-change: transform;. Once added,the “repaints on scroll” rect is gone.”
但是要小心,因为它永远不会总是应用,根据你的代码库,检查滚动性能问题指标,以确保“重绘滚动”是关闭的,对于我,我也必须禁用-webkit-clip-path属性(在我的实际的代码库 – 不在演示版本中提供),这是在其中一个子div中设置的,请参阅：
解决方法
首先,滚动的perf问题我喜欢在“渲染”窗格中的几个复选框上翻转：
瞬间,我们可以看到这个div被称为“滚动重绘”.然后,您可以在实验层面板中验证：
(我右键单击树中并选择“显示内部图层”btw)
现在,大的“更新层树”成本通常是由层的LOTS或几个尺寸非常大的层造成的.在这种情况下,我们真的没有.但是我们确实有一个滚动层没有得到合成滚动.
复合滚动==快速滚动==通常默认.但是在这样的情况下,我们回到“主线程滚动”,这是真的很慢和吸吮.在正面方面,crbug.com/381840即将修复,应自动修复此测试用例.好极了！但是现在我们可以解决它.
你确实提到你尝试了意志变化,没有任何效果,但尝试自己已经很好了.它属于具有溢出集的元素,在本例中为.map-search__results选择器.添加意志变换：变换.一旦添加,“滚动的重绘”直到没有了.然后用时间线测量,它更好.
这是一个前/后视图：
祝你好运！
