分析Flex应用的内存泄露问题

光明使者

随着Web 2.0技术的深入发展，Flex成为很多企业级应用的前端展示层。虽然Flex应用运行于FlashPalyer虚拟机之上，但是开发人员仍然会遇到一些内存泄露问题，那么如何分析和定位根源呢？IBM工程师王鹏最近撰文详细描述了检测Flex应用内存泄露的方方面面。
　　Flex采用ActionScript语言作为脚本语言，运行在FlashPlayer虚拟机之上，其垃圾回收机制概括如下：

Flex应用的对象在内存中被映射成树形结构。这很好理解，每个Flex应用总有一个Application的入口被称为根节点（Root），垃圾收集器从根节点开始遍历每个对象，对可达对象标记为"有效"（有一种例外就是弱引用）。而在这棵树之外的孤岛对象或者由于循环引用形成的孤岛对象集合被标记为"无效"，垃圾收集器会在合适的时间销毁这些无效对象，完成一次垃圾收集。而垃圾收集器是运行在虚拟机中的一个低优先级的守护进程，为了不影响性能，它只在必要的时候才运行。例如在向操作系统申请新内存空间的时候，发生异常的时候等等，因此内存并不是实时回收的。

　　在Flex应用开发过程中，主要存在两种泄露情况：

• 显式引用：由于表达式赋值或者对象参数传递等原因，已经"无用"的对象被保持引用，导致虚拟机无法正常回收。
• 隐式引用：由于事件监听注册等操作，导致对象之间存在引用，产生泄露风险。
  

　　针对以上泄露问题，文章建议大家采用Adobe公司在Flex Builder 3中提供的Profiler工具来分析和定位泄露根源：

• 内存快照法：通过对于相同操作做反复内存快照（Profiler工具支持）比较，找出持续增加的对象实例，就可能发现泄露根源。
• 游荡对象法：当Flex应用特别复杂时，可以利用Profiler 工具中的"Find Loitoring Objects"查找游荡对象，比较不同状态转换之间的对象变化，可能会发现泄露的对象。
  

　　当然，凡事应以"预防为主"，所以作者最后总结了几点开发建议：

• 对于显式引用，要尽量减少对临时对象的引用，尤其是全局变量、静态变量、使用单例模式创建的变量对临时变量的引用。这些变量包含stage、systemManager、application、MVC框架中Model和Controller，还有以Manager命名的对象等等。另外，临时变量本身要尽量做到高内聚性，对象内部尽量减少对外部对象尤其是全局对象的依赖。
• 对于隐式引用，使用弱引用方式注册事件监听器，将最后一个参数useWeakReference设置为true：a.addEventListener("Leak", b.leakHandler, false, 0, true); 这样做的结果是垃圾回收器在做标记时，会忽略a对于b的引用，如果b没有被其他对象引用，垃圾回收器就把它标记为"无效"进而回收，从而避免内存泄露。
  

　　内存泄露一直是开发社区普遍关注的问题，即使在虚拟机时代，某些泄露问题仍然值得大家讨论和研究。