为什么未正确且以一致的方式清理节点和侦听器? [英] Why isn't nodes and listeners being cleaned up properly and in a consistent way?

问题描述

我正在调查与节点数有关的内存泄漏的原因，但是当我查看角度在做什么时，我只是感到困惑，因为结果不够一致，无法得出清晰的分界线.发生了什么事.

I'm investigating the cause of a memory leak having to do with the nodes count, but I'm just getting confused when I look at what angular is doing, because the results are not consistent enough to draw a clear line of what is happening.

我创建了一个非常简单的应用程序，它具有1个控制器和2个视图.每个视图使用相同的控制器:

I've created a really simple app, it has 1 controller and 2 views. Each view use the same controller:

core.controller('CoreCtrl', [function() {

  var core = this;

  core.helloWorld = function() {
    console.log('hello world');
  };
}]);

core.config(['$routeProvider', function($routeProvider) {
  $routeProvider
    .when('/test1', {
      template: '<a href="#/test2" ng-click="core.helloWorld()">Go to test 2</a>',
      controller: 'CoreCtrl',
      controllerAs: 'core'
    })
    .when('/test2', {
      template: '<a href="#/test1" ng-click="core.helloWorld()">Go to test 1</a>',
      controller: 'CoreCtrl',
      controllerAs: 'core'
    })
    .otherwise({redirectTo: '/test1'});
}]);

然后，我在Chrome开发工具中记录时间轴，在视图之间快速切换然后每隔一秒切换一次，正如您在图形中可以清楚看到的那样.

I then record a timeline in the Chrome dev tools, alternating between switching between the views quickly and then every other second, as you can see clearly in the graph.

这是结果:

如您所见，在快速切换的第一阶段之后，节点数大量下降，然后我开始缓慢地切换视图，然后又快速地切换.切换之后，这次的节点数下降甚至没有接近第一个下降，并且此后节点继续上升.

As you can see after the first period of switching quickly, the nodes count drop massively, then I start switching views more slowly and then fast again. This time after switching more quickly the drop of nodes count is not even close to that of the first drop, as well as the nodes continuing to go up after that.

这里有两件事对我不利:

There are 2 things here that are off to me:

• 为什么切换视图后节点和侦听器的数量持续增加，而在一定时间后才下降? - _ - _ - _ - _-难道这不应该是锯齿状的吗，因为每个视图开关都应该清除节点和侦听器?

• Why does the nodes and listeners count keep going up after you switch view, only dropping after a certain period? Shouldn't this be more of a sawtooth pattern, - _ - _ - _ - _- since each view switch should do a cleanup of the nodes and listeners?

为什么第二个下降不如第一个下降那么大?

Why isn't the second drop as big as the first one?

在我看来，切换视图之间似乎有些事跟不上清理.或根本没有清除某些内容，这很奇怪，因为没有侦听器需要手动清除.

To me this seems like something can't keep up with cleaning up after itself when switching between the views. Or something isn't being cleaned up at all, which is odd since there are no listeners that would require manual cleanup.

任何人都无法从这些测试结果中了解吗?

Can anyone make any sense out of these test results?

推荐答案

为什么切换后节点和侦听器的数量不断增加 查看，一定时间后才下降?这不应该更多 锯齿形--_-_-_-_-，因为每个视图开关都应 清理节点和侦听器?

Why does the nodes and listeners count keep going up after you switch view, only dropping after a certain period? Shouldn't this be more of a sawtooth pattern, - _ - _ - _ - _- since each view switch should do a cleanup of the nodes and listeners?

由于您无法真正控制何时进行垃圾回收，因此内存不会立即崩溃.通常，浏览器仅在需要分配更多空间并且需要首先释放一些空间时才清理内存.

The memory does not go down immediately since you can't really control when the garbage collection will occur. Usually, the browser only cleans up the memory when it needs to allocate more space and it needs to free up some room first.

这就是为什么出于调试目的，您可以访问DevToolbar中的收集垃圾"按钮的原因().您应在每次录制的开始和结束时按此按钮，对于您而言，甚至在每次切换页面时都可以按此按钮.这样，您可以保证查看的是已使用的内存，而不是已占用的内存.

That is why, for debugging purposes, you have access to the "Collect garbage" button in the DevToolbar (). You should press this button at the beggining and end of every recording, and in your case, you could even press it everytime you finished switching the pages. This way you will have the guarantee that you are looking at the used memory instead of the occupied memory.

为什么第二个下降不如第一个下降那么大?

Why isn't the second drop as big as the first one?

这可能是由于相同的原因.

This is likely because of the same cause.

我分析了您的代码，并在手动触发垃圾回收之后获得了以下时间轴:

I profiled your code and I got the following timeline after manually triggering the garbage collection:

如您所见，似乎所有事件侦听器和节点都已正确清理.

As you can see, it seems like all the event listeners and nodes were correctly cleaned up.

尽管如此，如果您仍然在缓慢的计算机上遇到延迟，则很可能会发生这种情况，因为它们更快地耗尽了内存，并且需要更频繁地执行垃圾收集.

If, in spite of this, you are still experiencing lag on a slow machine, it is likely this happens because they run out of memory faster and need to perform garbage collection more often.

如 DevTools文档:

页面的性能被延迟或似乎频繁暂停. 可能是垃圾频繁收集的症状.垃圾 收集是指浏览器回收内存的时间.浏览器决定 当这件事发生时.在收集期间，所有脚本执行都将暂停. 因此，如果浏览器进行了大量垃圾收集，则脚本执行是 会变得很停顿.

A page’s performance is delayed or appears to pause frequently. This is possibly a symptom of frequent garbage collections. Garbage collection is when the browser reclaims memory. The browser decides when this happens. During collections, all script execution is paused. So if the browser is garbage collecting a lot, script execution is going to get paused a lot.

目前还不清楚这是否是您的应用程序面临的特定问题，因此您需要进一步调查.与这个简单的示例相比，您的应用程序中发生的事情可能更复杂.

It's not really clear if this is the particular problem your app is facing though, so you would need to investigate further. It's likely something more complex is going on in your app than in this simple example.

我发现Chrome DevTools CPU节制功能对于获取与我的用户使用该应用程序时一样慢.此外，Gmail小组的此演讲非常擅长解释如何跟踪这些问题.并显示内存使用率与应用程序性能之间的关系.

I found the Chrome DevTools CPU throttling feature very useful in getting the same slowness that my users were having with the application. Also, this talk by the Gmail team was great at explaining how to track down these issues and showing the relation between memory usage and performance of an app.

这篇关于为什么未正确且以一致的方式清理节点和侦听器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！