翻译：Flash Player 9资源管理策略，欢迎指正

• 一个游戏sprite订阅了它注册的enterFrame事件(一个sprite由很多frame组成，在切换到下一帧触发enterFrame事件，译者注)。移动一帧时，应用程序执行一些计算来大致确定一下游戏元素。在ActionScript 3.0中，每次你从显示对象列表删除sprite后把它的所有引用设置为null，应用程序还继续执行这一帧的代码直到被垃圾回收器删除。所以你必须在删除sprite对象时显式删除其enterFrame监听器。
• 考 虑一个Movie Clip，它通过注册Stage的mouseMove事件响应。这是在新显示列表模型中实现该效果的唯一方法。除非你记得删除该监听器，否则这clip将 在鼠标每次移动时继续执行，即使它已经被“删除”。默认情况下，这个clip总是会执行因为有一个它的引用存在于Stage的事件派发器。我在以后的文章 会讨论如何避免这个问题。

现在想象一下初始化若干sprite对象并在垃圾回收器执行清除之前删除它的含义，或者如果你删除所有引用失败会发生什么。你可以毫不留神的轻松耗 光CPU资源并导致程序或游戏慢的像爬虫，或者几乎完全使客户机器停止。目前没有办法强制Flash Player去删除一个显示对象并停止其执行。在这些对象从画布移除后需要Flash开发者用手工方式删除。

问题 2: Loaded content

要记住一点，已加载的SWF文件的内容现在和其它所有对象一视同仁，你能想象的到已加载内容可能遇到的问题。和其它的显示对象一样，没有办法显式的 从内存移除一个已加载的SWF文件和它的内容，或停止其代码运行。调用Loader.unload只是简单把到加载的SWF的引用置null；它（已加载 内容，译者注）将继续存在并执行直到它被下一次垃圾回收器执行清除操作时处理为止(假设到已加载内容的所有引用都已经被正确的清除)。

考虑下列两个场景:

• 你创建了一个外壳程序(原文shell，此处译为外壳程序较为合理)来加载你的试验Flash项目。这个前沿的试验性作品将CPU资源的使用发挥至极限。用户点击按钮来加载一个试验作品并查看它，然后点击按钮加载第二个试验。即使所有到第一个试验作品的引用都被清除，它还是会在后台运行，如果与此同时第二个试验作品启动运行，这将耗光处理器资源。
• 谋客户委任你创建一个应用程序加载由其它开发人员制作的ActionScript 3.0 SWF。他们把一些监听器添加到Stage或者引用一些外部资源到自己的程序。因为没办法卸载(外部资源)，它们将会待在内存中继续消耗CPU资源直到用户退出程序。即使已加载内容没有任何外部引用，他们还是会继续运行直到垃圾收集器清理它们。

当你设计一个应用程序去加载未信任的内容，意识到这些内容在你卸载之后还在继续执行很重要。这些内容按照相应的Flash Player 安全模型运行。在开发阶段就深入考虑程序中潜在的问题总是一个好主意。

使用 System.totalMemory

虽然System.totalMemory是个简单的工具，重要的是它是Flash开发者可以使用的第一个运行时profiling工具。它允许你检测Flash Player运行时刻占用多少内存。这使你有了一定能力在开发阶段profile程序，而不是使用系统监视器。更重要的是，它让你有可能在程序给客户造成严重事故前优先处理重大的内存泄露问题。抛出一个错误或终止你的程序总比使客户系统停滞完全停止要好的多。

有一个简单例子可以解释如何实现此功能：

ActionScript 代码
 
import flash.system.System;  
import flash.net.navigateToURL;  
import flash.net.URLRequest;  
...  
// check our memory every 1 second:  
var checkMemoryIntervalID:uint = setInterval(checkMemoryUsage,1000);  
...  
var showWarning:Boolean = true;  
var warningMemory:uint = 1000*1000*500;  
var abortMemory:uint = 1000*1000*625;  
...  
function checkMemoryUsage() {  
   if (System.totalMemory > warningMemory && showWarning) {  
      // show an error to the user warning them that we're running out of memory and might quit  
      // try to free up memory if possible  
      showWarning = false; // so we don't show an error every second  
    } else if (System.totalMemory > abortMemory) {  
      // save current user data to an LSO for recovery later?  
      abort();  
    }  
}  
function abort() {  
   // send the user to a page explaining what happpened:  
   navigateToURL(new URLRequest("memoryError.html"));  
}  

显然这段代码还有很多改进的余地。但希望它能演示这个功能背后的主要概念。

弱引用

ActionScript 3.0中有一个特性我很喜欢，这就是弱引用。可以这样描述：它们是某对象的引用但垃圾回收器在检测该对象的活动能力时不被当作引用计数。如有某对象只拥有唯一的引用并且该引用是弱引用，这个对象就会被垃圾回收器在下一轮执行时清除。

可惜的是，弱引用只能在两种场景下使用。第一个应用场景是事件监听器，也是最大的应用场合。因为事件监听器是造成垃圾回收器出现问题的常见引用类型 之一。我强烈建议永远对事件监听器使用弱引用。只须在你调用addEventListener 方法时把第5个参数设置为true，如下所示：

ActionScript 代码
 
someObj.addEventListener("eventName",listenerFunction,useCapture,priority,weakReference);  
stage.addEventListener(Event.CLICK,handleClick,false,0,true);  
// the reference back to handleClick (and this object) will be weak.  

了解更多关于弱引用的资料，请阅读我blog的这篇文章 weakly referenced listeners.

ActionScript 3.0的Dictionary对象也支持弱引用。创建新Dictionary对象时传true给第一个参数就可以轻松使该对象对其key使用弱引用，如下所示：

ActionScript 代码
 
var dict:Dictionary = new Dictionary(true);  
dict[myObj] = myOtherObj;  
// the reference to myObj is weak, the reference to myOtherObj is strong  

这里通往何方

资源管理是ActionScript 3.0开发中的重要问题。忽略本文描述的这些问题，可能导致反应迟钝的应用还有使客户系统完全停滞的潜在风险。没有任何方法能显示从内存删除一个显示对象并停止其代码运行。这意味着所有Flash开发人员有义务去正确清除程序中不再使用的对象。

ActionScript 3.0实际上增加了开发人员的工作，他们必须对其程序进行资源管理。Flash Player 9提供了一些新工具帮助开发人员进行内存管理。配合这些工具以及有效的策略和途径(我的系列文章，理解Flash Player 9垃圾收集机制)可使你在未来的Flash和Flex项目中成功的进行资源管理。

更多信息，请访问Flash开发者中心以及Flash Player开发者中心。

 关于作者