导致这种过度＆＃34;复合图层＆＃34;，＆＃34;重新计算风格＆＃34;和＆＃34;更新层树＆＃34;周期？

Question

我对我们的一个webapps中过多的“复合层”，“重新计算样式”和“更新层树”事件非常感兴趣。我想知道这里是什么造成了他们。

如果您将Chrome指向我们的快速移动流之一，请说https://choir.io/player/beachmonks/github，然后启用“FPS计”，您可以看到该应用在我们开启时大多数时间都能达到约60fps顶部。

但是，只要我向下滚动几条消息并保持屏幕原样，FPS费率就会急剧下降到10左右甚至更低。代码在这里做的是它呈现每个传入的消息，将其添加到顶部并向上滚动列表Npx，这是新消息的高度，以保持视口位置不变。

（我知道scrollTop会使屏幕无效但我已经仔细地命令操作以避免布局颠簸。我也知道每秒发生的同步重绘，它是由jquery.sparkline引起的，但它与此无关讨论。）

这是我在尝试描述它时看到的内容。 。

您认为可能会导致大量的图层操作？

Answer 1

需要重新绘制的所有元素上的CSS属性will-change: transform解决了我的复合图层太多的问题。

Answer 2

我有同样的问题。我通过减小图像的大小来修复它。

可滚动列表中有一些缩略图。每个缩略图的大小为3000x1800，但它们通过CSS调整为62x44。使用62x44图像减少了＆＃34;复合层＆＃34;。

所消耗的时间

Answer 3

有关可以提供帮助的ObjectType的一些信息

从我看到here它说

  

事件：复合图层

     

描述：Chrome的渲染引擎合成了图像层。

表示wikipedia

中复合词的含义

  

合成是将来自不同来源的视觉元素组合成单个图像，通常会产生错觉，即所有这些元素都是同一场景的一部分

所以这是我们实际看到的页面的过程，通过获取编码/调整图像的输出，解析HTML并解析CSS来创建我们看到的最终页面