导致这种过度"复合层","重新计算样式"和"更新层树"循环的原因是什么？
Ale*_*ong 27 performance timeline profiling render google-chrome-devtools
我对我们的一个webapps中过多的"复合层","重新计算样式"和"更新层树"事件非常感兴趣.我想知道这里是什么造成了他们.
如果您将Chrome指向我们快速移动的流之一,请说https://choir.io/player/beachmonks/github,并启用"FPS计",您可以看到应用程序可以达到大约60fps的大部分我们处于领先地位的时候.
但是,只要我向下滚动几条消息并保持屏幕不变,FPS速率就会急剧下降到10左右甚至更低.代码在这里做的是它呈现每个传入的消息,将其添加到顶部并向上滚动列表Npx,这是新消息的高度,以保持视口位置不变.
(我知道scrollTop会使屏幕无效,但我已经仔细地命令操作以避免布局颠簸.我也知道每秒发生的同步重绘,它是由jquery.sparkline引起的,但它与此讨论无关.)
这是我在尝试描述它时看到的内容.
.
您认为可能导致大量的图层操作？
我遇到过同样的问题。我通过减小图像的大小来修复它。
可滚动列表中有一些缩略图。每个缩略图的大小为 3000x1800，但它们被 CSS 调整为 62x44。使用 62x44 图像减少了“复合层”消耗的时间。
Rob*_*ert -4
有关的一些信息Composite Layers可以提供帮助
从我在这里看到的内容来看，它说
事件：复合层
描述：Chrome 的渲染引擎合成图像层。
来自维基百科的复合词的含义
合成是将不同来源的视觉元素组合成单个图像，通常会产生所有这些元素都是同一场景的一部分的错觉
因此，这是通过编码/调整图像大小、解析 HTML 和解析 CSS 的输出来制作我们实际看到的页面的过程，以制作我们看到的最终页面
- 并不是要消极，你对综合问题的看法实际上是正确的，但我实际上的意思是你可以改变你的答案，说这并不能回答问题，但我有一些信息可能会给你指点。 (3认同)
- 不知道这个答案与@Alex 发布的问题有何关系 (2认同)