一：加载swf库中的图片
new 的过程就是图片解压缩的过程。处于 Class 状态时，图片占用的内存和 SWF 文件中这个图片占用的磁盘空间一致，而一旦通过 new 解压成无压缩的 BitmapData 后，占用的内存会急剧增加。
不管是 PNG、JPG，还是矢量动画，new 之后的体积都会比原来大得多，因此不要随便将资源实例化后暂存。这个实例化过程理所当然是比较费时的，可能会出现卡的现象，但预先实例化，内存占用上是有很大区别的。
此外，如果选择设置 LoaderContext 使得全部资源加载到同一个域的话，有冲突的链接名是以先来先到的原则处理，即如果两个资源链接名相同，以先加载的对象为准。
二：将素材图片打包成一个SWF好处
打包成 SWF 有一个优点，SWF 可以让 JPEG 支持透明通道。一般来说，JPEG 压缩率高而不支持透明通道，PNG 压缩率低支持透明通道。将 PNG 导入 FLA 然后设置成 JPEG 压缩后，就能在压缩的同时保留透明通道，可以让支持透明通道的图片体积大大减小。
打包成 SWF 后，加载快且易于管理，是推荐方式。但这种做法限定你必须一次性加载所有资源，不能按需加载，有一定的局限性。比较适合加载 UI 皮肤，以及需要立即显示的图标等等。
还有一点需要注意：SWF 舞台上的内容，即使不显示出来也会消耗资源，因此请务必保证在发布时舞台为空。
三：不要直接用 Loader 加载文件
不同文件有不同的加载方式，文本和二进制文件只能通过 URLLoader 加载，而 PNG、JPG、SWF 等文件则可以通过 Loader 和 URLLoader 两种方式加载。如果资源需要长期保存，建议全部用 URLLoader 方式加载，在需要获取资源时，再通过 Loader 的 loadBytes 方法解析已经加载的二进制数据，之后再显示。
这样做目的是为了节省内存，因为 Loader 加载的资源会自动实例化（解码），PNG、JPG 会展开成无压缩的 BitmapData，SWF 舞台的内容也会全部实例化，他们会占用大量内存。先用 URLLoader 将他们作为二进制数据加载，需要时再解码实例化，就不会出现这个问题。
四：并发加载多文件加载还有一个问题：浏览器对并发下载数有限制，而这个限制和 Flash Player 的机制有冲突，所以一般情况下 Flash Player 同时发起的加载请求数最好不要超过5个， 否则加载事件可能会失效。为了解决这个问题，大部分人的解决方案都是采取队列加载，一次只加载一个文件。这在文件数量较小、单文件体积较大时并没有问题，但是当文件数量多、单文件体积小时，由于每次加载完一个文件后，重新请求下一个文件时需要等待服务器响应一段时间才开始加载，这样会浪费很多带宽，文件数量多时这个缺陷不能忽略，最多可能消耗2至3倍的加载时间。为了解决这个问题，我们需要一种特殊的队列加载模块，可以同时加载，但是同时加载的文件数量不能超过某个值。基本思路就是在加载完一个文件后，检查正在进行加载的文件数量，小于定值就取队列中的下一个地址新建加载，否则就什么都不做。
五：哈希表缓存当加载文件数量特别大的时候（诸如数百个），注意不要只使用数组保存。你可以创建一个 Dictionary，然后将名称作为键加载内容作为值，做一个哈希表，以后都直接通过名称从这个哈希表取值，会比遍历数组查找名称快很多。
六：主 SWF 加载问题SWF 必须加载完所有类后才能开始运行并显示图像，这样一来，第一个主 SWF 加载自己时就无法显示加载进度。解决这个问题有两种办法：一种办法很老但是实用，就是创建一个小 SWF 先显示出来，专门用来加载主 SWF，主 SWF 加载完毕后它就完成了使命。实际上这并不麻烦也是最稳定的一种方案。另一种方式是利用 Frame 元标签。在主 SWF 类名上面添加
[Frame(factoryClass="加载类类名")]
即可指定一个类作为加载类，它会在主 SWF 未加载完之前显示。这个类是一个两帧 MovieClip，当它自己加载完毕后，就可以反射出主 SWF 的内容并实例化。