Flex应用程序性能小贴士

本文来自：http://blog.csdn.net/lihe111/archive/2009/09/09/4534404.aspx

本文将保持简练的风格，直接提供10个贴心小贴士，让你的Flex应用程序快捷，精炼，反应迅速。

1号规则：保持“清洁”

总体来说，保持清洁的代码是个好的习惯，这样代码不仅格式恰当，可读，还不会有任何遗漏。没有内存泄露，没有cpu检测工具，就是一个清洁的对象，可以被GC回收。

1) 管理好你的事件监听- 这一消息有双重含义。首先，你应该经常移除不再需要的事件监听，因为它们会导致阻碍垃圾回收的对象引用，也就相当于内存泄露，这样子就很难进行跟踪，也不利于应用程序的性能发挥。你可以使用被引用的事件监听以尽量减少内存泄露，但是在不需要它们的时候，你仍然应该将它们清洁干净。第二就是：如果未能移除事件监听，则会引发性能问题。事件句柄可在你的应用程序里触发，你可能都未意识到。你在子组件里派遣一个事件，在DOM树（上层物件）上的句柄也会触发同一事件。如果你不希望发生此类情况，就要保持事件句柄的清晰；让它们处理特定的事件类型，当你的应用程序不再需要它们时，移除它们。

2) 卸除加载器和时间，当你使用基于加载器的物件（图像，SWFLoader等），调用unloadAndStop()以从加载器上卸除内容，并调用GC是一个好的习惯。这样可以释放有价值的系统资源，而如果不需要cpu cycles时，它们也不会被浪费。我经常为静态图像文件这么做，以防止过多使用内存。

3) 处理- 我发现在自定义组件，数据管理器或者在清理物件资源的视图里创建"dispose()"函数是一个非常好的办法。当你使用完物件时，dispose() 方法需要被清楚地调用，但是 dispose方法会处理任何需要的事项以清洁物件，释放资源。例如，停止计时器，移除事件监听，卸除加载物件，设定变参考为零，等等。基本上，要移除所有可能导致内存泄露或吞噬场景后的cpu cycles。是的，它用cpu cycles来调用dispose方法，但是相信我。这个方法非常之简单，计算复杂程度低，可以清楚地处理物件，而不是耗费时间，处理计算资源，及跟踪泄露和性能问题的预算。

2号规则: 如果你不一定需要做，就不要做

另外一个需要遵守的规则就是：如果你不一定需要做它，就不要做。不，我不是说“不要做你的工作”或“不要刷牙”。你应该做这些。我的意思是如果你不一定需要做的话，不要做计算程度复杂或非常耗费资源的事。

4) 恰当处理集合– 有几个问题我一直在观察，它们一直都是我每次看到时都最需要进行改变的。集合(ArrayCollection, XMLListCollection 等等) 是辅助类，包裹起初步结构如array或xmllist。为了让使用这些初步结构简单些，集合类会采取行动，这些行动计算程度复杂，但是你不会意识到。其原因就是每次你增加，移除或者更新一个条目，事件被派遣。每次你更新一个集合时，它们也会被派遣。

第一个贴士注重的是集合事件。如果你循环一个集合，更新了100,000个条目，100,000个事件就会被派遣。这会导致大量的性能实施，并会完全锁住你的应用程序UI.如果你不需要这些集合事件被派遣，你可使用disableAutoUpdate()函数以暂停集合事件。要确保完成后，或者再需要时，要将它们翻过来，使用enableAutoUpdate() 函数。

第二个贴士是，如果不需要，就不要使用集合。如果你就是需要循环100,000个条目，而你不使用数据绑定，那就使用任一array。

第三个关于集合的贴士仅在当你使用一个过滤器函数过滤集合时适用。如果采用了一个过滤器函数，你在给集合添加新物件时不需要每次都调用 refresh() 函数。在一些未预料的场合，这甚至会导致性能损失。例如，如果你有个与集合绑定的datagrid，还有另一个过程更新该集合。如果在集合上有个过滤器，当你调用结合的addItem方法时，它会被自动过滤。在添加条目之后调用refresh()方法会导致datagrid上的列表数据失效，从而使得整个的datagrid都要被重新有效化，重新编画。但是当进行优化时，可能轻易被忽略，并导致应用程序的性能发生急剧变化。

5) 使用延迟实例化 – 在缺省状态下，Flex内的所有导航容器（tab nav, accordion, viewstack等等）仅会在需要时创建子容器。这就防止了应用程序创建成千上万个不需要的组件，从而有助于保持应用程序的顺利运行，而不会占用资源或被锁住。如果不小心，改变创建原则可能会导致大问题。当创建你的自定义组件时，你还应该记住延迟实例化。不要在constructor里创建子物件。反之，覆盖createChildren() 方法，在那里创建。这样，你的组件也会遵循延迟实例化规则，但是不会有任何难以跟踪的性能问题。

6) 对象再循环 vs  新对象- 我之前已经探讨过这个问题，现在我再来谈谈它。再使用已有的对象往往比创建新的对象要“节省“资源些。它常与数据虚拟化联系在一起。

7) 如果没有发生改变，不要无效化/摧毁/或者重新验证你的对象。
如果你正在构建自定义组件，而有人改变了一个属性（通过getter/setter), 如果进入值没有改变，则不要无效化组件属性。因为这样会导致组件通过整个无效化/验证周期，从而使得属性被重新验证/提交，在显示列表上重新绘制对象。仅在真正发生改变时无效化属性。下面给出一个范例证实此概念：

public function set myProperty( value : Number ) : void
{
  if ( _myProperty != value )
  {
    _myProperty = value;
    propertiesChanged = true;
    invalidateProperties();
    dispatchEvent( new Event( "change" ) );
  }
}

3号规则：恰当使用语言

ActionScript 语言的特点可启动性能。

8) 动态/属性 VS. 类型化对象－动态和属的对象自有它们的地位。它们是属性，灵活，可以用任何特性进行修改，可在广泛的场合使用。然而，如果你有个类型化对象，而不需要使用属性，则使用强类型化对象。ActionScript 3的强类型化本质部分说明了它为什么快捷。强类型化对象的访问属性比动态对象的访问属性要快。

9)恰当使用常量-如果你有个从未改变的值，但是你一直引用它，使用常量。访问常量可以更快，而需要较少的运行时间。

10) 使用静态成员-静态属性和函数不要求调用或访问变量实例。既然它们不要求实例，从类直接访问它们就快得多，也不需要内存以实例化对象。应该将功用函数或不要求特定实例的属性的函数输入静态函数中。

说到第九点中的常量，通常我建议将常量静态化。这有助于你保持内存使用量最小化。而它不需要附属到类实例上。


所有这些看上去都似乎无关重要的编码活动，但是相信我，当这些原则累计起来，就能发挥大作用了。在现实里，它常常可归结为恰当的编码活动，而上面仅仅强调了你在创建应用程序时需要注意的几点事项而已。