Flex性能优化常用手法总结

[心 得] Flex性能优化常用手法总结

随着Flex越来越多的被人们所熟知，越来越多的互联网也开始了RIA应用 。众所周知，目前国内的宽带应用并不是像很多发达国 家发达，个人应用带宽基本上都是2M以下的，怎么样能够使你的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而造成的内存泄漏问题非常少。

 

-------------------------------------------------------------------------------

 

楼上说的确实不错， 这里设置为null是有些前提的， 在所有对象都用的对的情况下。 有一个很简单的例子，当两个对象相互引用， 这种情况下， 你怎么设置当前对象为null, 都不可能真正从内存中把它的引用计数为零， 这样内存垃圾回收是发挥不了作用的

 

--------------------------------------------------------------------------------

 

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

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

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

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