我正在尝试使用 Google Speed Tracer 分析我的 YUI3 应用程序。
这是第一个快照：
到目前为止一切顺利，ST 表示一个地方需要 195 毫秒。所以，我放大它：
更好，对吧？在这里，ST 将我带到了违规行：
但接下来是什么？我的意思是，这是行：
return ('scrollTop' in node) ? node.scrollTop : Y.DOM.docScrollY(node);
由于堆栈跟踪在这里结束，我假设它node.scrollTop被返回，这只是一个 JS 属性访问。
那么，在这一点上进行样式重新计算并产生 36 毫秒执行时间的说法背后的逻辑是什么？
谁能给我解释一下？
这里最有可能发生的是您已经累积了对需要重新计算样式的 DOM 和/或样式表的更改。但是大多数渲染引擎（当然是 WebKit）会尽可能地推迟样式重新计算（以及布局和渲染）。在最好的情况下，一旦当前事件处理程序将控制权返回给本机代码，样式重新计算、布局和渲染都会按顺序运行。
但是有许多事情可以强制提前重新计算或布局。最常见的是您访问scrollTop必须计算的 DOM 元素上的属性（例如， ）。其他属性，例如offset[Left Top Width Height]也通常强制重新计算和布局样式。浏览器无法“在后台”执行此操作，因为渲染引擎（在大多数情况下）与 Javascript VM 是单线程的，因此它通常必须等待您调用本机代码。
从您的屏幕截图中很难看出，但从我所见，您似乎在此事件之前解析了相当大的 HTML 块（价值 18 毫秒），这可能相当于大量的样式重新计算和布局（后者之后需要 26 毫秒）。我还在TableView._defRenderBodyFr()您的堆栈跟踪中看到，这使我怀疑就在调用此 getter 之前，您已经添加/更改了相当数量的表行。代码很可能构建了一个大的TableViewHTML 字符串，但您只在设置时为 HTML 解析（和 DOM 构建）付费innerHTML，但一旦代码尝试访问属性（在这种情况下scrollTop），您就为样式重新计算和布局。
通过减少受每个突变影响的行数，您应该能够将这些成本分解成更小的块（从而使 UI 线程有机会呼吸，并且通常感觉更灵敏）。我不是 YUI 专家，所以我不能告诉你如何在他们的 TableView 中做到这一点。