Flash内存清理、建议以及查找内存泄露的方法
转自：http://binary-house.spaces.live.com/blog/cns!A2B1EFCF718495C4!269.entry
一、Flash内存清理
Flash Player的garbage collection（GC）分两种运行方式，一种是“引用计数法”（Reference Counting），一种是“标记-清除法”（Mark Sweeping）。
1>、引用计数法是通过计算指向某个对象的引用的数量来确定是否清除该对象。如果一个对象的引用数量为0，表示程序无法再访问到该对象，则清除该对象；如果引用计数不为0，则不清除。这种方法运行代价较小，但是这种方法无法清除存在循环引用关系的对象集合。
2>、标记-清除法是从程序的根对象开始，遍历每个引用指向的对象。遍历经过的对象，则将其标记。最后清除所有没有打上标记的对象。这种方法比较彻底，但是运行代价较高。
FlashPlayer运行GC的时间并不固定，它会根据你的内存的占用情况来决定运行GC的时间。它会根据用户机器的内存值来设定一个阀值，然后将程序的占用内存量保存在该阀值左右。 正因为FlashPlayer这种“不确定”的GC机制，所以我们所要做的主要工作是确保创建的对象在不需要的时候可以被释放。确保对象可以被释放的大原则是没有外部引用指向该对象，除了一般情况下的没有将外部引用显示地设为null之外，以下的情况也会导致对象无法释放：
1>、没有remove监听的事件。比如，A对象对某个事件进行监听，监听函数（Event Handler）存在于B对象中，则相当于A对象会保存一个B对象的方法的引用，会导致B对象的内存无法释放。
解决方法：注意remove掉监听事件；或者在调用addEventListener（）时，将监听函数设为弱引用，但这种做法只适合一次性的监听。
2>、使用BindingUtils.bindSetter()、ChangeWatcher.watch()绑定某个对象之后，没有清除该绑定。道理同1，其实绑定某个对象，也就是监听其发出的PropertyChange事件。
解决方法：使用ChangeWatcher.unwatch()来清除绑定关系。
3>、声明了样式，并在样式中使用了嵌入式资源。比如在<mx:Style>标签中定义了样式名称。一个对象定义了样式，相当于对外声明了一个全局可用的样式，因此会到导致外部保存了该对象的引用，可能导致对象无法释放。
解决方法：解决方法很多，可以使用动态加载的样式，或者使用一个类或模块（Module）专门管理样式，这些解决方法取决程序的架构设计。
4>、使用ExternalInface.callBack()声明了对外的API函数。类似于情况1，一个对象对外声明了API，就使外部保存了指向该对象的引用。
解决方法：如果之前使用了ExternalInface.callBack("APIName", functionName)声明了一个API，则可以使用ExternalInface.callBack("APIName", null)取消该API。
5>、某些控件（类似TextInput），或者由这类控件构成的自定义组件，当焦点在这些控件上时，即使从DisplayList移除掉这些控件并删除引用，这些控件对象也无法释放。这个问题还有人提出来是一个Bug（http://bugs.adobe.com/jira/browse/SDK-14781）。这个问题估计和flash的焦点管理机制有关。
解决方法：目前的解决方法只能是等焦点重新转移到其他控件上（比如点击了其他控件），如此之前的控件对象就可以被GC释放。
那应该在什么时候做好垃圾清理的准备工作呢？之前有的文章说应该监听组件的removeFromStage事件，在其处理方法中进行垃圾清理的准备工作（清除引用，删除监听器，清除绑定关系，取消对外API等工作）。
其实这种方法不太确切。因为removedFromStage事件是当组件从DisplayList上移除的时候发出的，并不代表该组件对象的生命周期已经终结。只要程序保留了该组件对象的引用，可以再重新把该组件对象添加到DisplayList上（此时，该组件对象会发出addedToStage事件）。如果单纯在removedFromStage事件的监听函数中做该对象的垃圾清理准备工作，当组件重新被使用的时候，可能导致该组件对象原来的状态被破坏而无法使用。
因此，比较好的实践方法应该是，利用addedToStage、removedFromStage两个事件的对应关系，在removedFromStage事件的处理方法中执行垃圾清理的准备工作（清除引用，删除监听器，清除绑定关系，取消对外API等作），而在addedToStage事件的处理方法中执行removedFromStage事件的处理方法的反操作（设置引用、添加监听、设定绑定关系、设置API...也可以认为是一个组件对象的初始化操作），这样就可以保证一个组件对象被从DisplayList上移除后，可以释放相应内存；如果保存其引用，并将其重新添加到DisplayList上，又可重新使用。
二、另内存清理建议：
1. 使用实例成员(instance members),而不是用静态成员(static members),可以更容易地被profiler检查到.因此,尽可能地使用实例成员,而不要用静态成员.
2. 在事件完成之后,将其设为引用 而且/或者(and / or) 将其remove掉,有助于减少内存使用.
3. moduleLoader.unloadModule()会导致内存泄露,因此建议使用将moduleLoader.url=null.
4. module内存的释放时间是不确定(并不是在unload的时候).
5. 使用debug版本的module会导致大量的内存泄露,不管其容器是否使用.
6. 将一个程序块声明为module,而不要将其声明为application,并且设置各module专门为一个application进行优化,能大量节约内存.
7. 在适当的时候,为了内存可控,可强制使用垃圾收集器(garbageCollection).方法如下:
代码
{
import flash.net.LocalConnection;
var conn1:LocalConnection = new LocalConnection();
var conn2:LocalConnection = new LocalConnection();
conn1.connect( " gc " );
conn2.connect( " gc " );
}
catch (e:Error)
{
}
8. 使用release版的module swf.
9. 卸载debug版的flash player.
10. 安装release版的flash player.
三、关于查找内存泄漏
加载/卸载多个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报告是可以接受的，一个小得多的并可接受的最大内存值上限。
- 5) 通过上述操作后，当使用操作系统工具检查播放器进程，你可能会发现播放器内存属性仍然在增长，这个问题是播放器团队留下的研究空白区域。对于Internet Explorer，人们常发现最小化IE会导致内存应用减小，这竟味着IE的内存管理器在处理着什么，而不是播放器或你的应用程序减小了内存。我们不知道有什么编程方式可以强迫IE缩减内存。即使Flash认为所有对象应该已被卸载我们也要看看其它浏览器的内存增长报告