使用Safari Web检查器调试内存泄漏？

Question

仅供参考，我们正在调试使用angularJS 1.4.2和离子框架1.2.4与WKWebView开发的移动混合应用程序。

下面的多个快照用于显示之前和之后的事件。基于webkit memory debugging article，快照将显示尚未成为GC的实时JavaScript对象

快照2显示页面A和控制器A的默认状态。

快照5仍然在同一页面中，但经过一些计算并从PDFTron生成一个base64字符串pdf，以便在UIWebview上查看它。

快照10显示在退出页面A之后，并使用控制器C导航到页面C.

快照2和快照10的比较，所有base64字符串仍保留在那里。

问题：

1. 当snapShot的大小持续增加而不减少时是否正常？是否考虑内存泄漏？
2. 快照大小仅代表所有实时javascript对象，或者它会显示我们访问过的所有对象，无论它是否有效，就像应用程序中的某些历史对象一样？
3. 快照大小和快照实时大小有何不同？
4. 当导航到下一个控制器时，AngularJS将有助于破坏范围，我们还会在离子上禁用缓存。那么这些base64字符串也考虑内存泄漏项吗？

Answer 1

更新

发布了一篇关于内存调试的新文章。本文包括更详细的步骤和过程。

New memory debugging article

答案

在对应用程序进行了几个月的内存调试之后，我们在调试内存泄漏方面有了一些额外的发现。

1. 快照的大小会不断增加，因为在页面之间导航时可能会有一些静态对象或变量。
2. 如上所述，快照大小表示应用程序的当前活动内存使用情况，包括静态对象，UI元素和此控制器中处于活动状态的其他组件。
3. 而不是检查快照大小和快照实时大小，保留的大小和自身大小将提供有关内存使用情况的更多信息。自身大小是当前元素的大小，而保留大小是当前self元素被销毁后将释放多少内存。
4. base64字符串是考虑内存泄漏项。虽然在控制器端完成了适当的范围破坏和变量清除，但是存在一些泄漏，因为一些附加服务仍然引用该字符串。清理完所有剩余的引用问题后，base64字符串泄漏现在消失了。

内存调试步骤

对于那些可能还想在将来使用内存调试的人来说，这里有一些建议。 内存调试的当前步骤：

1. 从第A页 - 第B页导航，然后从第B页导航回到第A页。
2. 做快照。
3. 重复步骤1并执行另一个快照。
4. 将第一个快照与第二个快照进行比较。
5. 如果要进行另一次快照比较，请重复步骤1到步骤4。

*请记住始终拍摄最新快照。例如。使用快照5和6而不是1和2，因为较早的快照可能有机会成为GC，结果将不准确。

通过这些步骤，最好找出并确定内存泄漏部分。通常我们会跟踪对象，函数和数组计数。如果存在内存泄漏，则在比较快照时计数将增加。其他一些内存泄漏项将是对象内部的$$。这种对象可能会导致内存泄漏，因为该对象不再使用，但仍然被应用程序的其他部分引用。