javascript - Backbone.js 内存管理，增加 DOM 节点数

Question

情况:我正在开发一个相当复杂的单页 Backbone 应用程序，它可能会连续运行 8-12 小时以上。因此，需要确保应用程序不会泄漏，也不会因 X 小时后崩溃或速度急剧下降而出名。

应用:该应用基于 Backbone 构建(mv*), Zepto (类似于 jquery)，Curl (amd 装载机) & Mustache (模板化)。

问题:我刚刚征服了事件监听器。垃圾收集器似乎在清理这些家伙方面做得很好，但 DOM 节点数不会停止攀升。

问题:

• 是否有适当的方法来处理 DOM 节点，以便它们被正确地垃圾收集，或者这个 DOM 节点计数是一个永远不会减少的运行总数？
• 有没有人知道这些框架中的任何一个不能很好地处理 DOM 节点？可能是 mustache ？
• DOM 节点数是一个可靠的数字吗？

我真的只是想在我的冒险中寻找一个先机，以阻止这些 DOM 节点上升。任何帮助或指导将不胜感激(并相应地赞成)。

我假设一旦事件监听器被正确处理，DOM 节点计数就会自行管理，但事实似乎并非如此。

测试

---

• 第一次测试:6.8 分钟，110,000 个 DOM 节点

---

编辑:在没有时间轴记录的情况下，我重新运行了相同的脚本以随机混合链接并在大约 7 分钟处截取了一张屏幕截图。 GC 通过后，我得到了这些结果。

• 第二次测试:7.1 分钟，141,000 个 DOM 节点(没有时间线记录)

---

编辑:修复后:

升级 Backbone 并在各处使用 listenTo 和 stopListening 之后

• 7 分钟:6,926 个 DOM 节点(参见下面标记的答案)。
• 20 分钟:6,000 个 DOM 节点、20 个事件监听器、20 MB 内存。
• 25 分钟:11,600 个 DOM 节点、44 个监听器、内存 21.7 MB。
• 28 分钟:9,000 个 DOM 节点、22 个事件监听器、内存 21.7 MB。
• 30 分钟:13,700 个 DOM 节点，123 个事件监听器，内存 21.7。
• 31 分钟:7,040 个 DOM 节点，30 个监听器，内存 21.7。

Answer 1

I assumed that once the event listeners were properly disposed of that the DOM Node Count would just manage itself, but this doesn't seem to be the case.

如果我没听错，您是在尝试通过移除节点中的监听器来处理该节点，是这样吗？

请注意，将事件监听器添加到 DOM 节点并不会阻止该节点被垃圾收集，相关性是相反的:当节点处于事件状态时，将不会收集监听器函数。

• Is there a proper way to dispose of DOM Nodes so that they will be properly garbage collected, or is this DOM Node Count a running total that will never decrease?

要确保 DOM 节点可以被垃圾回收，您应该

1. 从文档树中删除节点。
2. 清除从 javascript 到节点的所有引用 AND 到同一子树中的所有节点，因为从 javascript 到子树中的一个节点的引用将包含整个子树。

因此，仅从节点中移除监听器以使其可收集是不够的。此外，如果您希望收集节点，则没有必要从节点中删除监听器。

当某些节点被 GC 收集并销毁时，DOM 节点数应该减少。该数字表示当前已创建但未销毁的 DOM 节点数量，因此它不应无限增长，除非存在内存泄漏。

• Is the DOM Node Count even a reliable figure?

是的。它应该是一个可靠的数字，因为每当创建一个新的 DOM 节点时它都会递增，而在它被销毁时递减。因此，实现起来非常简单，值得信赖。