Backbone.js 内存管理，增加 DOM 节点数 [英] Backbone.js Memory Management, Rising DOM Node Count

问题描述

情况:我正在开发一个相当复杂的单页 Backbone 应用程序，它可能会连续运行 8-12 多个小时.因此，需要确保应用程序不会泄漏，并且不会因 X 小时后崩溃或显着减慢而臭名昭著.

Situation: I'm working on a pretty decently complex single page Backbone app that could potentially be running for 8-12+ hours straight. Because of this, there's a need to ensure that the application won't leak and have a reputation for crashing after X hours or slow down dramatically.

应用程序:应用程序建立在 Backbone (mv*) 上，Zepto(类似于 jquery)、Curl (amd loader) &Mustache(模板).

The Application: The app is built on Backbone (mv*), Zepto (similar to jquery), Curl (amd loader) & Mustache (templating).

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

Problem: I've just conquered the event listeners. The garbage collector seems to be doing a fine job cleaning these guys up, but the DOM Node Count won't stop climbing.

问题:

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

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

I'm really just looking for a head start on my adventure to stop these DOM Nodes from rising. Any help or guidance would be greatly appreciated (and accordingly upvoted).

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

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.

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

• First Test: 6.8 minutes, 110,000 DOM Nodes

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

Edit: Without the Timeline recording, I reran the same script to randomly mash links and took a screenshot at around the 7 minute mark. After GC came through I had these results.

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

• Second Test: 7.1 minutes, 141,000 DOM Nodes (Without the timeline recording)

修复后:

升级 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.

• 7 minutes: 6,926 DOM Nodes (see marked answer below).
• 20 minutes: 6,000 DOM Nodes, 20 Event Listeners, Memory 20 MB.
• 25 minutes: 11,600 DOM Nodes, 44 Listeners, Memory 21.7 MB.
• 28 minutes: 9,000 DOM Nodes, 22 Event Listeners, Memory 21.7 MB.
• 30 minutes: 13,700 DOM Nodes, 123 Event Listeners, Memory 21.7.
• 31 minutes: 7,040 DOM Nodes, 30 Listeners, Memory 21.7.

推荐答案

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

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.

如果我猜对了，您正试图通过从中删除侦听器来处理节点，是这样吗?

If I got you right you are trying to dispose of the node by removing listeners from it, is that the case?

请注意，向 DOM 节点添加事件侦听器并不会阻止该节点被垃圾收集，依赖关系是相反的:当节点处于活动状态时，不会收集侦听器函数.

Note that adding event listener to a DOM node doesn't prevent the node from being garbage collected, the dependency is in opposite direction: while the node is alive the listener function will not be collected.

• 是否有正确的方法来处理 DOM 节点，以便它们被正确地垃圾收集，或者这个 DOM 节点计数是一个永远不会减少的运行总数?

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

To make sure a DOM node can be garbage collected you should

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

1. Remove the node from the document tree.
2. Clear all references from javascript to the node AND to all nodes in the same subtree as reference from javascript to one of the nodes in the subtree will hold whole subtree.

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

So it is not enough to just remove listeners from a node to make it collectable. Moreover, it is not necessary to remove listeners from a node if you want the node to be collected.

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

The DOM node count should be decreasing when some nodes are collected by GC and destroyed. The number indicates current amount of DOM nodes that have been created but not destroyed so it shouldn't grow indefinitely unless there is a memory leak.

• DOM 节点数是一个可靠的数字吗?

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

Yes. It should be a reliable figure as it is incremented whenever a new DOM node is created and decremented when it is destroyed. So the implementation is quite straightforward to trust it.

这篇关于Backbone.js 内存管理，增加 DOM 节点数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！