apache-flex - 显示Flex对象引用

Question

我的Flex应用程序中有一些内存泄漏问题，而我的问题的简短版本是：有什么方法（在AcitonScript 3中）找到给定对象的所有实时引用？

我有很多视图，每个视图后面都有演示模型（使用Swiz）。感兴趣的视图是TabNavigator的子视图，因此当我关闭选项卡时，该视图将从舞台上删除。从舞台上移除视图后，Swiz会将视图中的模型参考设置为null。我还从视图中删除了AllChildren（）。

但是，在对应用程序进行性能分析时，当我执行此操作并运行GC时，视图和表示模型都不会被释放（尽管两者都将彼此的引用设置为null）。视图使用的一个模型对象（尽管不是演示者）已释放，因此它并未完全损坏。

我今天才刚刚开始分析（肯定会相信不要过早优化），因此我想某处会有一些参考，但是我看不到哪里，调试功能将是非常有用的。并查看引用目标对象的对象列表。这是否有可能（如果不是本地的话），是否有一些轻量级的方法可以将此代码编码到将来的应用程序中以进行调试？

干杯。

Answer 1

假设您正在使用Flex Builder，则可以尝试使用Profiler。以我的经验，它对性能分析不是很好，但是对于发现内存泄漏很有帮助。

它不是最直观的工具，需要一段时间才能习惯它（我的意思是，实际上它会变得有用）。但是，我认为，花一些时间至少学习基础知识会有所收获。仅查看播放器全局使用了多少内存（System.totalMemory为您提供了一个非常粗略，不精确且经常令人误解的指标）与实际跟踪已创建每个对象的实例数量，仍然有多少实例之间存在巨大差异还活着，以及它们在哪里分配的（因此您可以在代码中找到潜在的泄漏并进行实际修复，而不必依靠黑魔法）。

我不了解FB Profiler的任何优秀教程，但这也许可以帮助您入门。

首先，启动分析器。取消选中性能性能分析并检查其他所有内容（启用内存性能分析，观察实时内存数据并生成对象分配堆栈跟踪）。

探查器启动后，您将看到有关应用程序对象的统计信息（按类分组）。此时，您可能需要调整过滤器。您会看到很多数据，很容易被淹没。现在，如果可能的话，请忽略所有原生于Flash和flex的东西，而专注于一些您认为应该收集的对象。

最重要的数字是“累积实例”和“实例”。第一个是到目前为止创建的实例总数。第二个是仍然存在的所述实例的数量。因此，一个好的出发点是使您的应用程序进入您怀疑泄漏的视图被创建的状态。对于“累积实例”和“实例”，应该看到1。

现在，执行所需的操作以清理该视图（导航至应用程序的其他部分，等等）并运行GC（在事件探查器UI中有一个按钮）。至关重要的一点是，您将根据自己的期望检查应用程序的行为（如果可以的话）。根据定义，在垃圾收集环境中自动查找泄漏几乎是不可能的；否则，不会有泄漏。因此，请记住这一点：您测试自己的期望值；您是知道对象生命周期的人，可以说：“这时应该已经收集了该对象；否则，应该有问题”。

现在，如果您查看的“实例”计数下降到0，则那里没有泄漏。如果您认为该应用程序泄漏，请尝试查找其他可能未正确处置的对象。如果计数保持为1，则表示您的视图已泄漏。现在，您必须找到原因和位置。

此时，您应该进行“内存快照”（Force GC按钮旁边的按钮）。打开快照，在网格中找到对象，然后双击它。这将为您提供所有引用该对象的对象的列表。它实际上是一棵树，可能每个项目依次包含许多反向引用，依此类推。这些是阻止收集您的视图的对象。同样，在右侧面板中，您将分配分配跟踪。这将显示所选对象的创建方式（非常类似于堆栈跟踪）。

您可能在那里看到大量的对象。但是最好的选择是将精力集中在那些生命周期比您要检查的对象（您的视图）更长的对象上。我的意思是寻找舞台，父视图等。如果可以的话，视图所依赖的对象而不是视图所依赖的对象。如果您的视图中有一个按钮，并且您添加了一个侦听器，则您的按钮将引用您的视图。在大多数情况下，这不是问题，因为按钮取决于视图，并且一旦视图被收集，按钮也是如此。因此，其想法是，由于对象很多，因此您应尽量保持专注，否则您将一事无成。这种方法颇具启发性，但以我的经验来看，它是可行的。

找到泄漏源后，请返回泄漏源，相应地更改代码（也许这不仅需要更改代码，还需要重构一点）。然后重复该过程，并检查您的更改是否达到了预期的效果。可能需要一段时间，具体取决于应用程序的大小或复杂程度以及您对该应用程序的了解程度。但是，如果您一步一步地去做，一次发现并解决一个问题，最终将消除泄漏。或至少是最糟糕，最明显的情况。因此，虽然有点乏味，但还是有回报的（顺便说一句，您最终将了解，在大多数情况下，对地球上的每个事件处理程序使用弱引用会浪费时间，使每个单个变量等；这是一个启发性的经验；）。

希望这可以帮助。