了解Google Speed Tracer的报告

Question

我正在尝试使用Google Speed Tracer配置我的YUI3应用程序。

以下是第一张快照：

到目前为止，ST表示占地时间为195毫秒。所以，我放大了它：

更好，对吗？ ST把我带到违规行：

但下一步是什么？我的意思是，这是一行：

return ('scrollTop' in node) ? node.scrollTop : Y.DOM.docScrollY(node);

由于堆栈跟踪在这里结束，我假设返回node.scrollTop，这只是一个JS属性访问。

那么声称在这一点上进行样式重新计算会产生36毫秒执行时间的原因是什么呢？

有人可以向我解释一下吗？

Answer 1

这里最有可能发生的是您已经对需要重新计算样式的DOM和/或样式表进行了累积更改。但是大多数渲染引擎（肯定是WebKit）会尽可能延迟样式重新计算（以及布局和渲染）。在最好的情况下，一旦当前事件处理程序将控制权返回到本机代码，样式重新计算，布局和呈现都会按顺序运行。

但是有很多事情可以迫使早期重新计算或布局。最常见的是您访问必须计算的DOM元素上的属性（例如，scrollTop）。其他属性（如offset[Left Top Width Height]）也通常会强制重新计算样式和布局。浏览器不能“在后台”执行此操作，因为渲染引擎（大部分）与Javascript VM是单线程的，因此它通常必须等待您调用本机代码。

从你的屏幕截图来看，这有点难以辨别，但从我所看到的情况来看，你似乎在此事件发生之前就已经解析了很大一部分HTML（价值18ms），这可能相当于一个很大的风格重新计算和布局（后者仅需26ms）。我还在堆栈跟踪中看到TableView._defRenderBodyFr()，这使我怀疑在调用此getter之前，您已添加/突变了相当多的表行。 TableView代码最有可能构建一个大的HTML字符串，但是只有在innerHTML中设置时才支付HTML解析（以及DOM构造），但是一旦代码尝试访问您支付了样式重新计算和布局的属性（在本例中为scrollTop）。

您应该能够通过减少每个突变影响的行数，将这些成本分解为更小的块（从而使UI线程有机会呼吸并且通常感觉更具响应性）。我不是YUI专家，所以我不能告诉你如何在他们的TableView中做到这一点。