Mikel
[转载]Flash务实主义——Loading « 岩屋(乐在其中).
加载形式
FLASH加载文件有两种常规方式：一种是URLLoader，可以加载文本、二进制数据或 URL 编码变量形式的数据，然后转换成简单的文本形式或值对字符串形式；一种是Loader，可以将加载的图像文件转换成BitmapData，也可以解析 SWF文件。(Socket, LocalConnection这些非常用类不在讨论范围)
加载的资源应被统一管理以方便调用和重用，管理方式一般有两种：一种是将资源全部打包进SWF；一种是加载分散资源通过配置进行管理。我将对这两种管理方式进行介绍。
资源打包成SWF
在编辑FLA文件时，我们可以导入各种图片，并为其设置链接名。除手工逐个操作外，我们可以借助JSFL进行自动化处理（请参考http://bbs.9ria.com/thread-31730-1-1.html）。
由此生成SWF后，再用Loader加载。这时候我们需要的不再是舞台上的内容，而是SWF应用域里包含资源的类。可以用Loader的 contentLoaderInfo.applicationDomain.getDefinition()方法来获得这个类，并实例化。如果在执行加载 方法时第二个参数LoaderContext设置成了ApplicationDomain.currentDomain，使得被加载的SWF与主SWF共 享同一应用域，那么直接使用getDefinitionByName ()方法也可以获得这个类。
通过new的方式就可以实例化获得的BitmapData或MovieClip类，然后使用。因此项目中要想得到一个资源，只要知道它的链接名即可。链接名是自行设定的有意义的名字，完全可以当做资源的唯一ID。
需要注意的是，new的过程就是图片解压缩的过程。处于Class状态时，图片占用的内存和SWF文件中这个图片占用的磁盘空间一致，而一旦通过 new解压成无压缩的BitmapData后，占用的内存会急剧增加。不管是PNG、JPG，还是矢量动画，new之后的体积都会比原来大得多，因此不要 随便将资源实例化后暂存。这个实例化过程理所当然是比较费时的，可能会出现卡的现象，但预先实例化，内存占用上是有很大区别的。
此外，如果选择设置LoaderContext使得全部资源加载到同一个域的话，有冲突的链接名是以先来先到的原则处理，即如果两个资源链接名相同，以先加载的对象为准。
打包成SWF有一个优点，SWF可以让JPEG支持透明通道。一般来说，JPEG压缩率高而不支持透明通道，PNG压缩率低支持透明通道。将PNG导入FLA然后设置成JPEG压缩后，就能在压缩的同时保留透明通道，可以让支持透明通道的图片体积大大减小。
打包成SWF后，加载快且易于管理，是推荐方式。但这种做法限定你必须一次性加载所有资源，不能按需加载，有一定的局限性。比较适合加载UI皮肤，以及需要立即显示的图标等等。
还有一点需要注意：SWF舞台上的内容，即使不显示出来也会消耗资源，因此请务必保证在发布时舞台为空。
资源分散加载
如果文件要按需加载，或者不希望用SWF打包增加维护成本，或者有大量文本以致于不能用FLA导入，那我们只能逐个文件加载。
因为资源可能处于不同目录，命名也不规范，也会有扩展名，这样的路径在代码中作为ID存在是不合适的。所以一般都会有一个文本配置文件，将这些文件路径和一个名称对应起来，并提供给模块加载。加载完成后则是通过这个名称来获取资源。
不要直接用Loader加载文件
不同文件有不同的加载方式，文本和二进制文件只能通过URLLoader加载，而PNG、JPG、SWF等文件则可以通过Loader和 URLLoader两种方式加载。如果资源需要长期保存，建议全部用URLLoader方式加载，在需要获取资源时，再通过Loader的 loadBytes方法解析已经加载的二进制数据，之后再显示。
这样做目的是为了节省内存，因为Loader加载的资源会自动实例化（解码），PNG、JPG会展开成无压缩的BitmapData，SWF舞台的 内容也会全部实例化，他们会占用大量内存。先用URLLoader将他们作为二进制数据加载，需要时再解码实例化，就不会出现这个问题。
并发加载
多文件加载还有一个问题：浏览器对并发下载数有限制，而这个限制和Flash Player的机制有冲突，所以一般情况下Flash Player同时发起的加载请求数最好不要超过5个， 否则加载事件可能会失效。为了解决这个问题，大部分人的解决方案都是采取队列加载，一次只加载一个文件。这在文件数量较小、单文件体积较大时并没有问题， 但是当文件数量多、单文件体积小时，由于每次加载完一个文件后，重新请求下一个文件时需要等待服务器响应一段时间才开始加载，这样会浪费很多带宽，文件数 量多时这个缺陷不能忽略，最多可能消耗2至3倍的加载时间。
为了解决这个问题，我们需要一种特殊的队列加载模块，可以同时加载，但是同时加载的文件数量不能超过某个值。基本思路就是在加载完一个文件后，检查正在进行加载的文件数量，小于定值就取队列中的下一个地址新建加载，否则就什么都不做。
BulkLoader（http://code.google.com/p/bulk-loader），
LoaderMax（http://www.greensock.com/loadermax）
都提供了这个功能，当然我的GhostCat也通过AssetManager（复合QueueLoadOper实现）提供了这个功能。复杂度实际上并没有比线性加载高多少。
这样做，加载时等待服务器返回时依然有文件在下载，多个加载过程会平衡消耗带宽，带宽就不会被浪费。一般同时加载数量为2就足够了。但如果你的文件特别零散，使得两个文件同时等待返回的几率也很高，也可以考虑设置2以上的值。
哈希表缓存
当加载文件数量特别大的时候（诸如数百个），注意不要只使用数组保存。你可以创建一个Dictionary，然后将名称作为键加载内容作为值，做一个哈希表，以后都直接通过名称从这个哈希表取值，会比遍历数组查找名称快很多。
使用ZIP或其他打包形式
如果你不喜欢SWF这种打包方式，也可以选择ZIP打包，详情请阅读http://nochump.com/blog/archives/15。
ZIP的优点是可以用winrar打开，不需要借助专门的工具，缺点则是解压需要时间。当然，你也可以考虑用二进制自定义一个封装格式，这样也能加密资源文件，但这需要你自己编写一个管理工具。当然，这也不算特别麻烦。
使用ShareObject缓存
虽然有浏览器缓存，但实际上这种缓存持续不了几天，因为浏览器一向都有最大缓存限制。一般你看几个视频，这个缓存空间就消耗得差不多了。为了不让 Flash加载的文件缓存被冲洗掉，你可以将加载的文件的二进制数据（Loader是 contentLoaderInfo.bytes，URLLoader则要用二进制方式加载获取其data属性）保存在ShareObject里，并添加 版本号以便更新，下次加载就直接取这个数据。这个操作会请求大量ShareObject空间，因此FLASH会弹出提示让用户确认。如果你担心用户不确 认，可以在游戏其他地方向用户说明情况并要求他们点击确认按钮。
现在不少游戏都采用了这种做法，效果还是可以的。
显示总体加载进度
我们可能在开始时会加载多个文件。比起每加载一个文件显示一次进度条从0%到100%的过程，显然是显示所有文件总体的加载进度，只进行一次从0% 到100%的过程更具有实际意义。但是FLASH做这件事情并不太容易，因为它想要获得一个文件的大小就必须去加载它，而这个加载需要时间，你没有办法从 一开始就立即获得所有文件的大小。
实现的方法只有一个，就是在程序中或者配置中写死所有文件的总大小，然后根据所有文件已经加载字节数的总和来计算和显示进度。
至于这个总和如何获得，可以在程序中写上trace，实际加载运行一次便能获得实际所有文件大小总和，也可以做专门工具计算，也可以用操作系统来直 接查看总和，总之方法不是问题。而且，即使这个值不准确也无大碍，因为加载流程依然是按加载完所有文件作为依据，而这个进度只是用来显示，就算不准也不过 是未到100%就结束或者到了100%也要等待一段时间才能结束。这无伤大雅。
之前所说的类库都提供了这样的功能。
主SWF加载问题
SWF必须加载完所有类后才能开始运行并显示图像，这样一来，第一个主SWF加载自己时就无法显示加载进度。解决这个问题有两种办法：
一种办法很老但是实用，就是创建一个小SWF先显示出来，专门用来加载主SWF，主SWF加载完毕后它就完成了使命。实际上这并不麻烦也是最稳定的一种方案。
另一种方式是利用Frame元标签。在主SWF类名上面添加
[Frame(factoryClass="加载类类名")]
即可指定一个类作为加载类，它会在主SWF未加载完之前显示。这个类是一个两帧MovieClip，当它自己加载完毕后，就可以反射出主SWF的内容并实例化。
可以看这篇文章：http://www.bit-101.com/blog/?p=946。
而我自己的加载类模板则是这个，可以作为参考：
