javascript - 使用 ng-repeat AngularJS 构建大表后，Internet Explorer 中的垃圾收集需要很长时间

Question

我正在使用 AngularJS (1.2.26) 的 ng-repeat 指令构建一个大表(3,000 多行)。数据是一个非常简单的时间和温度数组[[time, temperature], [time, temperature], ...]。

这是数据在表格中的显示方式(使用 Slim templating ):

  table.table.table-bordered
    thead
      tr
        th.time.first-child= t('Time')
        th.temperature.sensor
    tbody
      tr[bindonce ng-repeat="item in readings"]
        td.datetime
          span.date bo-text="formatDate(item.time)"
          span.time bo-html="formatTime(item.time)"
        td bo-text="item.reading.temperature | number: 2" 

如您所见，我们正在使用 bind once库来减少 Angular 观察者的数量。这是一份报告，因此我们不需要维护数据绑定(bind)。

加载数据和呈现报告在 Chrome 或 Firefox 上大约需要 4 秒，在 Internet Explorer 上大约需要 8 秒 (11)。但是，在 Internet Explorer 上构建表格后，浏览器最多需要两分钟时间执行垃圾收集(根据 UI Responsiveness 选项卡)。

我需要更多的“声誉”来发布图片，所以我会尽可能地描述正在发生的事情。

整个表格渲染过程是 xhr.onreadystatechange 事件监听器的结果(此后已在 1.3 中从 angular 中删除)。每行和跨度都使用来自 jQuery 的 appendChild() -> insertBefore() 函数或来自浏览器的 innerHTML 函数添加到表中。这些发生了数千次，占了我之前提到的 ~8 秒。这些完成后，紧随其后的是几行垃圾收集，总共需要 60 多秒。

在没有输出图片的情况下，这是在最后一个 appendChild() 之后开始执行的时间列表，后跟总执行时间(柱的长度在窗口中)。

1. 0.24 秒，0.0065 毫秒
2. 0.36 秒，13.83 毫秒
3. 0.85 秒，0.31 毫秒
4. 10 秒，0.0042 毫秒
5. 57 秒，25.54 毫秒
6. 60 秒，0.048 毫秒

然后，在剩下的过程继续之前，还有大约 10 秒的间隔。

我不明白这里发生了什么，因为每个单独的垃圾回收时间很短，但是它们之间的间隔很长。我对浏览器中的垃圾收集了解不多，所以我妨碍了我的理解。这不会发生在 Chrome 或 Firefox 中。

我遵循了有关分析内存分析的各种指南。我不相信有内存泄漏。同样，由于我的声誉，我无法添加更多链接，但我关注了标题为“JavaScript 内存分析”的 Chrome 和标题为“改进 UI 响应能力”的 IE。

我不确定其中的另一部分是否相关，但我会在这里提及以防万一。当您在此延迟期间运行分析 session 时，IE 表示延迟发生在 requestAnimationFrame https://github.com/angular/angular.js/blob/master/src/ng/raf.js#L15 AngularJS $$RAFProvider 函数。这可能与 AngularJS 为通过 ng-repeat 添加的每一行触发一个“enter”事件有关。到目前为止，我一直在尝试禁用该动画事件，但不幸的是。

如有任何建议或疑难解答提示，我们将不胜感激。具体来说，如果我可以在垃圾回收上添加一个断点以查看发生了什么，那就太好了，但我认为我无法做到这一点。

Answer 1

经过大量调查，我认为我弄清楚了问题是什么，或者至少是一个潜在的问题。

我正在渲染的表格有两列 - 时间和温度。时间列有两个 <span>元素。因此，对于每一行，Angular 都在为“输入”动画标记元素，就像它为 ng-repeat 的每个元素所做的那样。 .作为 Angular 动画过程的一部分，Angular 通过 $RAFProvider 从浏览器请求一个动画帧。 .当我在 Internet Explorer 中分析该过程并查看调用堆栈时，这就是巨大的延迟所在。我最初认为这不是问题所在，但经过大量故障排除后，我开始认为 Internet Explorer requestAnimationFrame 方法无法像 Chrome 或 Firefox 一样快地处理 ~9000 次调用。

为了解决这个问题，我选择实现 ngInfiniteScroll它工作得很好。如果用户真的想要完整的报告，我们将通过不同的代码路径生成完整的 3,000 行报告。