javascript - 在 SAPUI5/OpenUI5 中创建和删除 View 时内存泄漏

Question

我正在使用 OpenUI5/SAPUI5 编写测试应用程序，即使经过大量测试、优化和研究，我似乎仍然存在内存泄漏。

我有几个附加了 Controller 的 View ，并使用 SAPUI5 的 SplitApp 控件在它们之间导航。每当我返回时，我都会像这样破坏 View :

// Get current page
var sCurrentDetailPage = this.oSpiltApp.getCurrentDetailPage().getId();
// Go back
this.oSpiltApp.backDetail();
this.oSpiltApp.removeDetailPage(sCurrentDetailPage);
// Destroy current page
sap.ui.getCore().byId(sCurrentDetailPage).destroy(true);

因为我无法摆脱 View 维护的所有内容，所以我在 Controller 的 onExit 函数中手动添加了对其元素的销毁调用(在销毁 View 时调用 onExit)。尽管对 View 的销毁调用也应该销毁它的子元素，这似乎摆脱了更多的元素，但仍然不够。我只使用 SAPUI5 提供的事件和点击处理程序，它们在调用 destroy 时应该分离，如果 View 订阅了我在 onExit 中取消订阅的事件。

问题:

如果我创建并导航到一个新 View ，然后返回(销毁该 View )，似乎只有大约一半的分配内存再次被释放。所以我会打开一个 View ，返回并在 Chrome 中拍摄堆快照，它显示 20MB。然后我打开和关闭相同的 View 5 次，最后得到 20.5 MB。因此，对于这个特定的 View ，在销毁它时不会删除 100KB。如果该应用程序整天都在使用(这是预期的)，这可能会导致旧移动设备出现问题。有没有人有这个问题的经验？非常感谢。

编辑

我用 Chrome Timeline 记录了内存使用情况。我反复创建两个 View 并再次销毁它们。对于 JS 堆，我得到以下结果:

所以它似乎随着时间的推移而大幅增长。

对于节点和监听器，我得到了这个结果，这对我来说似乎没问题:

你会说这是内存泄漏还是我 react 过度？这个测试靠谱吗？非常感谢。

Answer 1

浏览器保留内存是正常的。 JavaScript 是一种垃圾收集语言，因此使对象引用无效或使用 delete 键盘不会触发垃圾收集器释放该内存。

现代浏览器中的内存垃圾收集通常分两个阶段进行:

1. 检查对象图。任何未被“全局上下文”中的任何内容引用的对象，例如浏览器中的 window 对象被标记为“陈旧”。

2. 下次运行垃圾收集器时，所有以前“过时”的对象都会释放内存并返回以供浏览器使用——请注意，从操作的 Angular 来看，这些内存并没有“释放”系统。浏览器会保留这些内存地址，以防再次需要它们。

3. 释放“陈旧”对象后，浏览器再次返回步骤 #1 以将下一批对象标记为“陈旧”。

此外，大多数浏览器只允许垃圾收集器运行设定的毫秒数，因为在此期间浏览器中的 UI 在技术上是无响应的，因此被检查的对象图不会在运行中发生变化。

内存泄漏的真正测试是利用内置的浏览器工具进行内存分析。我知道 Chrome 和 Firefox 有这个功能。其次，随着时间的推移——我的意思是超过 10 到 15 分钟——你应该看到分配给浏览器的内存呈锯齿状，短期趋势是上下趋势，但总体趋势是持平的。

      .      .      .      .      .
    . |    . |    . |    . |    . |
  .   |  .   |  .   |  .   |  .   |
.     |.     |.     |.     |.     |

如果您在一段时间内看到整体趋势呈上升趋势的锯齿状图案，则可能表示存在内存泄漏。

                                 .
                        .      . |
               .      . |    .   |
      .      . |    .   |  .     |
    . |    .   |  .     |.       
  .   |  .     |.       
.     |.

真正的真正测试是使用浏览器附带的内置性能监控工具。