知了博客

优化主界面内存占用点滴：
目的：在系统资源有限的情况下，使占有内存能控制在50M
一共41张图片：
1.用cs4工具，自带解析图片：内存从24M-58M
2.URLoader, 一张张解码，用完释放,发现解码速度太慢，造成内存泄漏，达不到效果



网络资源：
来源：http://www.uxtracer.com/blog/?p=20

项目现状
Flash相册程序，在播放60张图片后（60是相册图片数量上限），内存占用接近1G。

当前技术实现
使用Loader加载图片文件，然后新建BitmapData对Loader进行draw操作保存位图数据，随后loader.unload()释放原始图片资源。播放某一张图片时，取出对应的位图数据，根据当前播放窗口大小进行平滑缩放，随后生成Bitmap对象，展现。

优化思考1：所有已加载的图片都保存其位图数据，导致内存占用过大。那么可以考虑限制位图数据对内存的占用总量，如果位图数据内存占用超出一个设定值（比如200MB）后销毁离当前播放index最远的图片位图数据。
问题：由于已加载数据可能会被销毁，所以会经常发生图片需要再次加载的情况，影响相册观看流畅度。另外，通过测试发现，即使设定一个比较宽松的上限值（比如200MB），也只能容纳几张图片的位图数据。
该方法损失了用户体验，但问题仍然没有得到较好解决。

优化思考2：BitmapData位图数据占用内存过大，如果Loader加载图片文件后不转化为位图数据，而直接保存loader对象，会不会减小内存占用？
经过试验发现，一个1280*800的jpg（130K），通过Loader加载进舞台并显示，不做任何处理，内存占用高达4MB。将loader对象从舞台上remove掉，只保留引用，内存占用仍不见减少。同时此做法会带来一个问题，loader对象的直接缩放会产生锯齿，这对相册程序而言是不可以接受的。
此路不通。

优化思考3：既然直接保存BitmapData对象很吃内存，那么我通过JPGEncoder将其转化为ByteArray再进行保存，势必会减少开销。需要使用图片时，再通过 loader.loadBytes来加载ByteArray数据。
经过试验发现，经过JPGEncoder转化后的ByteArray数据很小，只占用几十KB内存，效果明显。使用loader.loadBytes加载ByteArray显示也很顺利很流程。但一个致命的问题出现了，JPGEncoder执行效率非常低下，即使只是宽高1280*800的BitmapData，转化过程也会长达6秒之久（我的机器配置不低），更糟糕的是，由于Flash是单线程运行环境，所以此操作会导致整个界面卡住，程序陷入假死状态。
（延伸阅读：使用Vector优化JPGEncoder执行效率 异步JPGEncoder）

优化思考4：经Laan提醒，想到 ByteArray不需要通过对BitmapData数据JPGEncode来做，通过URLLoader指定BINARY方式读取图片文件，其data 属性就是JPG或者其它压缩格式的ByteArray数据。
试验通过，问题终于得到顺利解决。

优化效果
经过上述优化，60张图片播放后，内存占用仍然不到100M，优化效果显著。

最后，说一下如何强制Player进行垃圾回收
如果只想在Debug Player中使用，则可以使用System.gc();
如果想在所有运行环境都能运行，则可以使用下面这一段垃圾回收触发代码（查看原帖）：

try {
new LocalConnection().connect(“gcHacker”);
new LocalConnection().connect(“gcHacker”);
} catch (e:Error) {
}