flash查找内存泄漏

    加载/卸载多个SWF模块和子应用是涉及内存泄漏最常见场景。每天，我们了解到播放器更多的如何进行内存管理及其特性，因此该总结了。
    当调试怀疑在加载/卸载SWF时发生了内存泄漏，我一般会执行以下操作：

1）建立应用程序或测试来多次加载和卸载SWF（至少3次），迫使垃 圾收集器在每次加载或卸载后工作，接着使用性能分析工具来查看内存中有多少个模块的 xxx_FlexModuleFactory或子应用程序的SystemManager的副本。如果超过1个，保持加载和卸载查看该数值是否继续增长。任 何模块或SWF引入不同风格的新组件将需要利用StyleManager注 册，StyleManager始终首先被加载。你可以在主程序中或通过CSS模块预加载样式来防止其发生。如果加载第二个副本可能在此处停留，因为播放器 或FocusManager可能一直挂起，如果你看到超过2，绝对是内存泄漏了，您应该使用Profiler来寻找泄漏。
2）经过多次装卸后，采用内存快照，然后再多次加载和卸载再采用快照。清除所有的过滤器，删除百分比，用类名排序并手动比较每个类的实例数量。它们可能是完全匹配地，除了少数字符，弱引 用。一切都值得怀疑和调查。
3)我想清理SWF得到所有引用，接下来在调试器中多次加载和卸载并查看console面板信息。在调试面板中查找以 [UnloadSWF]标记开始的行:  告诉我播放器认为SWF卸载后一切都清理了，请注意，清理可能不是马上就执行的，即使有时播放器请求GC（垃圾 回收）后若SWF还有内部引用会得到“later”稍后清理。如果不明白，回到第2步比较内存快照查找可能泄漏的对象。
4)现在我确信即使播放器在卸载SWF后认为一切OK了，但System.totalMemory却仍在增加，最后的测试将其导出为 release版并运行在release播放器中。调试版播放器会将调试信息编译进SWF中，这样会歪斜 System.totalMemory的值（值会不正确）。目前测试，一旦通过第3步，release播放器的System.totalMemory报告 是可以接受的，一个小得多的并可接受的最大内存值上限。
通过上述操作后，当使用操作系统工具检查播放器进程，你可能会发现播放器内存属性仍然在增长，这个问题是播放器团队留下的研究空白区 域。对于Internet Explorer，人们常发现最小化IE会导致内存应用减小，这竟味着IE的内存管理器在处理着什么，而不是播放器或你的应用程序减小了内存。我们不知道 有什么编程方式可以强迫IE缩减内存。即使Flash认为所有对象应该已被卸载我们也要看看其它浏览器的内存增长报告。