关于flex程序的内存优化

 

    网上不少flex开发者发表了很多关于flex程序内存优化的方法，首先感谢大家无私的分享自己的经验。我相信真理不止一个，一种解决方案放到不同的环境中它不一定会起到立竿见影的效果，但是这至少是解决问题时可以去尝试的一种解决方案。下面做一下记载：

第一篇：

不知道具体是谁的原创，里面有一些有争议的说法

基本原则：
1.  从外部加载 媒体（Media）
      Heider提到了一个常用的Flex最佳实践——限制嵌入到应用/SWF文件 中的媒体的数量，如图像、影片及mp3等资源都可以从外部的SWF文件加载。 
Flex框架 可以直接将图片 、mp3及字体等资源编译 到SWF中。当你想让最终用户获得全部资源时，这种方式确实能派上用场，但是这会导致你的应用长时间停留在“Loading”阶段。 

2. 在嵌入式字体中限制字符集
Heider建议在嵌入式字体中限制字符集以降低SWF文件的总下载时间： 
当你在Flex中嵌入一种字体时，你就会获得该字体的全部字符的支持。尽管这可能是你想要的，但你确信你需要全部字符么？例如，在一个只面向英文的应用中，你确信你真的想花时间下载中文字符数据么？
3. 缓存框架  
        Heider回顾了Flex 3 support for runtime-shared-libraries （RSL）这篇文章：

从Flex 3开始，你可以将Adobe 签名的框架——RSLs缓存到Flash Player的cache中。这有两个好处。首先，缓存在Flash Player cache中的签名的框架RSLs可由所有配置好的Flex应用共享。换句话说，如果某人的应用已经下载了500k的签名的框架RSL，并且该RSL仍旧 在Flash Player cache中，那么你的应用就可以使用缓存下来的RSL。其次，即使某人清空了其浏览器缓存，对Flash Player cache也没有任何影响。
4. 考虑模块化  
Heider谈到了将Flex应用划分成模块的好处：减少字体加载时间的另一种方式就是将你的Flex应用划分成模块。使用模块的一个好处在于当加载和卸载模块时你能完全操控它。
之所以要划分成模块的最后一个原因是他们更快，而且我能即时加载它们。换句话说，在启动时唯一需要加载的模块就是 Step1.swf 模块。因此，在使用模块的情况下，最终用户节省了启动时间，但是当他从一个模块切换到另一个模块时却需要花更多时间，因为每个模块都需 要以JIT形式加载。在我的应用中，只有当用户首次在steps 1-5之间切换时需要花更多时间。 
5. 推迟实例化  
      Heider围绕着Flex组件的“creationPolicy”属性及何时实例化应用的不同部分给出了很多建议。
      如果你想减少从数据下载到用户真正可以使用的总时间，当务之急就是推迟实例化。这项技术背后的理念就是直到应用真正使用的时候才在内存中创建对象 。
      尽管推迟实例化技术会在应用的整个使用过程中导致少许——通常不那么明显——的延迟，但与长时间的启动延迟相比，它还是可接受的。推迟实例化的另一个好处在于内存使用的优化。

以上原则来自Jun Heider在O’Reilly的InsideRIA站点上发表了一篇精彩的文章，该文章就如何加快Flex应用的启动速度 提出了很多建议，以帮助用户减少看见讨厌的“Loading”对话框的出现时间。他深入探讨了问题的不同方面，并对每种技术的优势和劣势进行了评判。Heider还谈到了一个“实验性”的条款——“使用流”，这是他在讨论Dirk Eismann的帖子（Building monolithic Flex SWFs that still startup quickly.”）时谈及的。Eismann提出一项技术以利用Flash Player中的多个frames以在部分应用中达到流的目的。查看所有的帖子以更多地了解该技术及关于加快Flex启动速度的建议。

内存释放优化原则
1. 被删除对象在外部的所有引用一定要被删除干净才能被系统当成垃圾回收处理掉；
2. 父对象内部的子对象被外部其他对象引用了，会导致此子对象不会被删除，子对象不会被删除又会导致了父对象不会被删除；
3. 如果一个对象中引用了外部对象，当自己被删除或者不需要使用此引用对象时，一定要记得把此对象的引用设置为null;
4. 本对象删除不了的原因不一定是自己被引用了，也有可能是自己的孩子被外部引用了，孩子删不掉导致父亲也删不掉；
5. 除了引用需要删除外，系统组件或者全局工具、管理类如果提供了卸载方法的就一定要调用 删除内部对象，否则有可能会造成内存泄露和性能损失；
6. 父对象立刻被删除了不代表子对象就会被删除或立刻被删除，可能会在后期被系统自动删除或第二次移除操作时被删除；
7. 如果父对象remove了子对象后没有清除对子对象的引用，子对象一样是不能被删除的，父对象也不能被删除；
8. 注册的事件 如果没有被移除不影响自定义的强行回收机制，但有可能会影响正常的回收机制，所以最好是做到注册的事件监听器都要记得移除干净。
9. 父对象被删除了不代表其余子对象都删除了，找到一种状态的泄露代码不等于其他状态就没有泄露了，要各模块各状态逐个进行测试分析，直到测试任何状态下都能删除整个对象为止。
内存泄露举例：
1. 引用泄露：对子对象的引用，外部对本对象或子对象的引用都需要置null；
2. 系统类泄露：使用了系统类而忘记做删除操作了，如BindingUtils.bindSetter()，ChangeWatcher.watch()函数 时候完毕后需要调用ChangeWatcher.unwatch()函数来清除引用 ，否则使用此函数的对象将不会被删除；
类似的还有MUSIC，VIDEO，IMAGE，TIMER，EVENT，BINDING等。
3.  效果 泄露：当对组件应用效果Effect的时候，当本对象本删除时需要把本对象和子对象上的Effect动画 停止掉，然后把Effect的target对象置null; 如果不停止掉动画直接把 Effect置null将不能正常移除对象。
4. SWF泄露：要完全删除一个SWF要调用它的unload()方法并且把对象置null;
5. 图片泄露：当Image对象使用完毕后要把source置null;(为测试)；
6. 声音、视频泄露: 当不需要一个音乐或视频是需要停止音乐，删除对象，引用置null;
内存泄露解决方法：
1. 在组件的REMOVED_FROM_STAGE事件回掉中做垃圾处理操作（移除所有对外引用（不管是VO还是组件的都需要删除），删除监听器，调用系统类的清除方法）
先remove再置null, 确保被remove或者removeAll后的对象在外部的引用全部释放干净;
2. 利用Flex的性能优化工具Profile来对项目进程进行监控，可知道历史创建过哪些对象，目前有哪些对象没有被删除，创建的数量，占用的内存比例和用量，创建过程等信息；
总结：关键还是要做好清除工作，自己设置的引用自己要记得删除，自己用过的系统类要记得做好回收处理工作。 以上问题解决的好的话不需要自定义强制回收器也有可能被系统正常的自动回收掉。

此篇的争议点：

当你在处理一个对象的泄露问题的时候，如果是这个对象本身不能被清除，那么无论你怎样清除其引用到的对象，对这个对象本身的回收都毫无意义。需要关注的是事件监听，以及相关联的对象对这个对象本身的引用。

在当前的对象已经可以被成功清除的时候，他对外部的所有引用自然都会失效，那么将它们设置为null，对外部的对象的清除也是毫无意义的。当然，设置成null也没有坏处。在当前对象不清除的前提下，就需要清除其引用的对象的时候，设置为null才是必须的。

不要无脑地处理内存泄露问题，尤其是设置null这件事情。虽然全部设置null并没有坏处，但如果依赖于这样的想法，会对你解决问题思路的造成影响。一遇到泄漏就去考虑null的问题，实际上会绕弯路，因为真正因为未设置null而造成的内存泄漏问题非常少。

2. 父对象内部的子对象被外部其他对象引用了，会导致此子对象不会被删除，子对象不会被删除又会导致了父对象不会被删除；
注意这里的父/子对象所指的是addChild这类关系的东西。一个对象是另一个对象的属性，并不符合这一条。

3. 如果一个对象中引用了外部对象，当自己被删除或者不需要使用此引用对象时，一定要记得把此对象的引用设置为null;
上面说了，不需要使用此引用对象，需要。但自己被删除的时候不需要。

4. 本对象删除不了的原因不一定是自己被引用了，也有可能是自己的孩子被外部引用了，孩子删不掉导致父亲也删不掉；
同2

8. 注册的事件如果没有被移除不影响自定义的强行回收机制，但有可能会影响正常的回收机制，所以最好是做到注册的事件监听器都要记得移除干净。
结论是对的，但第一句话纯属胡扯。不移除事件将会100%造成泄露，弱引用则是另一回事，但不推荐。

为什么说弱引用很危险？就是弱引用出现问题具有不确定性，gc的时机正好的话，可能就没事，但也可能有事，这会形成一个难以重现的BUG，而这种BUG是最难解决的。如果出现了连锁反应，你会无从下手。
内存泄露至少我还有profile，有据可查，这个怎么弄？
不明白弱引用到底是怎么回事就不要用它，否则总有一天要吃大亏的，而且这样也不利于养成良好的编程习惯。

第二篇：

这应该是笔者阅读client_server_performance.pdf这本书的笔记和小部分项目开发经验

1.避免容器的深层嵌套(因为每个容器都会对其子容器进行计算和调整，一般建议HBox,VBox最好不要超过3层，但对于复杂系统这个很难避免) 
2.对于容器和空间的位置和尺寸尽量采用绝对坐标和硬编码。(减少Flash Player深层次的嵌套计算) 
3.合理恰当的使用Grid容器，对于能用普通容器如HBox，VBox实现的尽量不要采用Grid(Grid嵌套层次深) 
4.避免使用重复、冗余的容器嵌套，如：
 1) 在Panel，Application中添加一层VBox，Panel,Application本来就是继承于VBox的，添加无谓的VBox只能降低你系统的性能。
 2) 对于自定义的容器减少重复多余的父容器，比如：
  <mx:VBox backgroundColor=" #FFCCCC" borderStyle=" solid">
   <myComponent xmlns=" *" />
  </mx:VBox>
 你完全可以采用下面的写法，对于myComponents可能它本身就是VBox
  <myComponent xmlns=" *" backgroundColor=" #FFCCCC" borderStyle="solid" /> 
5.延迟实例化导航类容器(Deferred Instantiation Navigator Containers)
   如ViewStack, Accordion, TabNavigator等，本身就提供了延迟实例化的功能，你只需要修改其creationPolicy='auto'即可，它将只实例化第一个要显示的子控件，其余的将在需要的时候实例化。 
6.对于flex的效果(Effects)要做到尽量平滑(Smoothly)，比如延长它的持续时间(duration)，避免使用bmp格式的图片作背景。 
7.对于DataGrid的复杂ItemRenderer，尽量用Canvas而不是VBox or HBox，这个和Flex 1.5中是不同的。 
8.如果DataGrid的ItemRenderer是ComboBox等，尽量用ItemEditor而不是ItemRenderer，只有当选中的cell才会显示其Renderer(避免一次性把所有的cell Renderer都画出来) 
9.记得随时Remove 没有用的Listener或采用弱引用，这个我在事件机制中提到过(URL...); null不用的变量和数组。 
10.对于大批量的数据采用需要的时候去取或者分页 
11.提前声明频繁使用的变量,如:
var l:int=list.length;
var w:int = stage.stageWidth;
for(var i : int=0; i < l; i++){
 list[i].x = w -100;
}
这样也能提高Flex的性能，可能很多人都会不屑，但至少对于Flex来讲它能减少不必要的计算，改善性能，我想这个编程习惯问题要改还真是不容易，至少我写了1年多直到最近才注意到这个问题。 

另外和代码组织有关的建议，如：
 1) 系统性的常量写在一个常量类里头并用const关键字，一些ItemRenderer代码尽量独立成一个文件而不是直接到处都写
 2) 不要在界面元素中引用一大串的parent.parent.parent...，一旦界面重新组织将给你带来很大麻烦。如果你用Cairngorm框架，那么就应该用ViewHelper，尽量的松耦合你的代码。 
13.修改 production-mode 属性为true，2.01在文件flex-webtier-config.xml中。它一般是产品发布的时候要设置的，你可以理解为c++的 Release和Debug版本之间的差异。 
14.如果你用FDS，那么尽量用Remote Object 而不是Http Service or Web Service，因为前者的效率最高 
15.对你的系统进行压力测试，Adobe有一个测试工具，叫Flex Stress Testing Framework
(rul:http://labs.adobe.com/wiki/index.php/Flex_Stress_Testing_Framework).
它能提供对RPC中的RTMP， AMF，HTTP测试，一般的商业测试软件不支持前两者的测试，
该软件完全免费，你可以到Adobe官网上下(URL:  http://download.macromedia.com/pub/labs/flexstress/flex_stressfw_p2_060407.zip )