原文在这里:Garbage Collection with Flex and Adobe Air

我终于有时间来整理在flexcamp上演讲的东西并写篇博客了。就在flexcamp前一个月,我几乎天天和FlexProfiler争吵而且关系很紧 张(笔者注:结论不一致)。因此我觉得在flexcamp中讲讲性能监测和垃圾回收(GC)是非常合适的话题。没错,想要脱离GC去获得性能提升简直是不 可能的。如果你想改善你的应用的内存管理你必须知道Flashplayer(和adobe AIR)如何管理内存分配和释放。

有许多博客、文章、演讲、等等都介绍过GC和profiling,我在文章底部将他们列举了出来。对于每天使用Flex并且需要来优化内存消耗的初学者和中等经验的开发者来说,我这篇文章是有帮助意义的。

虚拟机(VM)

flashplayer是基于一个虚拟机(精确的来说是2两个,一个是为actionscript2的一个是为actionscript3的),当你需要创建新的对象时虚拟机动态分配内存,例如下面的代码来创建一个新的对象:

var o:Object = new Object();

在启动时VM事先占用(reserve)了一些内存,当上面的代码被执行时VM决定那个对象放在应用内存的什么位置以及它需要占用多少空间。当你创建对象
时,VM可能使用启动时占用的所有内存,如果需要,再向操作系统请求更多的内存。除非你有一个程序仅仅是毫无疑义的创建新对象,正常的应用在执行时必然会
有一个对象变为无用的时候,例如,为了正确的执行程序,它不需要存在了。你将会看到,理解一个对象何时不再被需要是不容易的事情。就现在,让我们加深我们
能够检测到它。在Flash
VM架构,你不能明确的说“删除它‘,内存使用是被VM本身所管理的,VM本身负责检查哪些对象是无用的并擅长他们,这样的机制就叫做垃圾回收。

垃圾回收

那么,作为一个程序员我们能做什么?好的,你可以让垃圾回收变得容易,让我们来看看下图能为我们揭示什么内容。
flex 垃圾回收-LMLPHP

在启动阶段应用占用了一些要使用的内存,比如说4个块。当你创建了一个对象,VM将第一个空位分配给它。我们说,过一会当o1不再需要是你将它设为
null。你创建一个新的对象o2,你希望o2代替o1。有时它发生,有时它不会发生,这取决于垃圾回收机制,这样一种非常复杂的过程,我们不在这里描
述。这时我们已经得到一个教训:“设置一个对象为null不一定能够释放它占用的内存‘。这取决于flash中已经实现的垃圾回收的方式,GC由重分配触
发而不是由删除触发,这意味着GC周期在你声明new Object()的时候运行而不是你设置它为null时运行。

内存消耗

如果你不得不使用AS3和Flex,你可能知道你可以动态的添加UI元素到图形界面中,通过一个简单的方法叫做addChild(),相反的方法是
removeChild(),它用来移除一个显示元素从UI中。更精确的来说,元素是从视图中删除,但是这不意味着它已经被垃圾回收了。让我来介绍一个简
单的场景给你展示很容易相信removeChild()的事实。

许多Flex应用从服务端加载数据并根据返回的值动态展示它,通常情况视图代码被隔离到一个组件中,经常被称为renderer,它负责展示来自服务器的
数据。我没设计一个非常简单的renderer,它由两个文本字段,嵌入一个VBox中,数据显示是field1和field2,被提供的对象的属性作为
值来源:

 xmlns:mx="http://www.adobe.com/2006/mxml"
borderStyle="solid" width="200"
>
> [Bindable] private var _field1:String;
[Bindable] private var _field2:String;
override public function set data(value:Object):void {
_field1 = value.field1;
_field2 = value.field2;
}
]]>
>
text="{_field1}" />
text="{_field2}" />
>

让我们通过一个简单的函数来模拟数据载入,它返回对象的一个数组:

private function getData():Array 
{
var a:Array = new Array();
for (var i:uint = ; i< ; i++)
{
var o:Object = new Object();
o.field1 = "field "+Math.random().toString();
o.field2 = "field "+Math.random().toString();
a.push(o);
}
return a;
}

为了渲染数据,我们使用一个简单的函数,来创建一个renderer,设置它的data属性,并添加到VBox中:

private function loadData():void 
{
vbox.removeAllChildren();
var array:Array = getData();
for (var i:int = ; i < array.length; i++)
{
var rend:MyRenderer = new MyRenderer();
rend.data = array[i];
box.addChild(rend);
i++;
}
}

你看到那个危险的声明了吗?还没有?让我来显示给你,为了模拟一个重复的操作,我添加了一个timer,它会每N秒都调用加载数据的函数:

private function init():void 
{
var t:Timer = new Timer();
t.addEventListener(TimerEvent.TIMER, tick);
t.start();
}

现在,试着运行一下profiler(笔者注:flexbuilder3中的工具),你看到像下图一样一直增长的图形了吗?

flex 垃圾回收-LMLPHP
恭喜,我们已经发现了一个内存泄漏!内存泄漏发生在重复的动作并且内存消耗持续增长而不是保持恒定。你发现了那个危险的声明了吗?它就是当你创建
renderer是发生的。为什么?因为你认为removeAllChildren()从内存中移除了那些renderers。错误!正像上面所说,这个
方法仅仅从显示树(显示列表)中移除了renderers,事实上,正如你从profiler中看到的,renderers还在那儿,继续消耗着内存。

技术上讲这不是一个内存泄漏,因为这没有任何东西阻止垃圾回收器去清除来自renderers的内存。事实上这种情形下,内存泄漏发生在,当有些对象被认
为使用了renderer(例如一个listener),即使当你从显示树中移除了它。在这个例子中renderers是“自由的‘,可能被垃圾回收,但
是,他们不是这样的,因此,结果仍然与内存泄漏是相同的,不断增长的内存消耗:

flex 垃圾回收-LMLPHP
有许多技术来解决这种情况,我们来展示两个:缓存renderers和动态缓存。

缓存

让我们假设,你实现知道需要多少renderers,一个方法来解决内存泄漏就是在启动是来创建一个renderers的缓存:

private var cache:Array = new Array();
private function initRenderers():void
{
for (var i:int = ; i < ; i++)
{
renderers.push(new MyRenderer());
}
}

我们于是可以这样修改我们的loadData方法:

private function loadData():void
{
container.removeAllChildren();
var array:Array = getData();
for (var i:int = ; i < array.length; i++)
{
var rend:MyRenderer = cache[i];
rend.data = array[i];
container.addChild(rend);
i++;
}
}

正如你所见,我们不再创建新的renderers,而是在缓存中查找一个。

很多情况下,你事先不知道多少数据从服务器返回,而且不知道你需要多少renderers,这时你需要一个动态缓存。

动态缓存

动态缓存是基于一个弹性的机制,你有一个地方可以来查找一个renderer:如果缓存中有一个,那就返回它,否则一个新的被临时创建,最好来看看下面的代码:

public class MyRendererCache extends Object 
{
private static var cache : ArrayCollection = new ArrayCollection();
public function MyRendererCache()
{
super();
for ( var x : Number = ; x < ; x ++ )
{
cache.addItem( new MyRenderer() );
}
}
public static function getRenderer() : MyRenderer
{
var renderer : MyRenderer;
if ( cache.length <= )
{
renderer = new MyRenderer();
}
else
{
renderer = cache.removeItemAt( ) as MyRenderer;
}
return renderer;
}
public static function setRenderer( renderer : MyRenderer ) : void
{
cache.addItem( renderer );
}
}

在构造函数中,你操作缓存用最小数目的renderers,比如说2个。这个缓存有两个静态方法,getRenderer和setRenderer,第一
个是来获得一个renderer,第二个是当结束时返还给它。这种方式下内存中renderers的数量可能增长超过最小的数目,但是仅是临时的,因为
GC会在他们当不在被引用时删除他们。一个重要的问题是跟setRenderer有关,当你不再需要一个renderer时,你必须把它返回给
cache,否则我们又陷入内存泄漏中,如上解释的那样。为了达到这个目的,我们来利用renderer的remove事件,remove事件是当一个
UI元素被从显示列表中移除时被触发。例如当我们调用removeAllChildren(),这样的事件对于每一个renderer来说都会被触发。我
们可以这样修改renderer:

 xmlns:mx="http://www.adobe.com/2006/mxml"
borderStyle="solid" width="200"
remove="onRemove()"
>
private function onRemove():void {
MyRendererCache.setRenderer(this);
}
....
>

如果现在来运行profiler,你会注意到,内存增长到一个给定的点并且保持稳定,如下图所示:

flex 垃圾回收-LMLPHP

恭喜,你已经解决了内存泄漏!

建议性GC

除了偏向于自动的GC过程,adobe还允许程序员来建议干涉性的GC。这个命令在flash.system包中的System.gc(),通过这篇文章
“强制垃圾回收过程‘,但是在我的经验来看,这仅仅是一个模糊的干涉建议,它能解决某些情况,因此在开始时它值得一试,当你需要一个快速的方法来节省一些
内存时。

05-07 15:46