[size=small]1、线性化下载过程
一般的下载队列,是一口气推入n个loader,然后逐个下载,下载完了调用start,开始整个程序。
由于是线性过程,这个时候下载流程比较好控制。假如碰到被下载的一个swf中,又下载别的图片、音乐之类,就成了树形过程了。LoaderMax在这方面的处理是利用一个requireWithRoot 属性,指定该Loader隶属于哪个容器。一旦指定,那么这个Loader所下载内容,就当作容器的一部分。
比如 main.swf > (a.swf > a.mp3) > (b.swf > b.jpg), a.mp3 和 b.jpg都远大于两个swf。
当main在下载的时候,先下a.swf,完了下b.swf。而a.swf中会去下载a.mp3,b.swf则是下载b.jpg。所以很可能出现的情况是a,b.swf都下载好了,还在同时下载a.mp3和b.jpg。但这个时候main已经算下完了,要start了...
如果在a.swf下载a.mp3时设置requireWithRoot = root,b.swf也一样。那么main.swf在a.swf之后下a.mp3,直到a.mp3下载完了,才算a.swf下完。这样就把一个树形流程又改为线性的了。
2、预估文件大小
在下载文件时,都知道有个请求过程,这个过程中文件的总大小是不知道的。这样对显示进度就是个麻烦事儿。像以前碰到公司内网关上安了2b防火墙,进来的数据都隔那儿堵着,等cache满到一定大小才一下子返回。搞得每次在公司看loading都是一闪而过,这不是因为快,是因为前面堵着呢,只能傻等着....LoaderMax在这方面采用了预估文件大小,利用一个estimatedBytes 属性,先假设要下的文件大小是多少。这样一来,即使请求还没来,下载进度还是有的。如果网络不出问题,等到请求返回了,马上就拿精确的文件大小替换预估值,让进度始终保持在用户眼前,而不会傻等。这个属性的默认大小是 20000 (20k)。
3、tween式初始化
这个就不多说了,还是那句话,没用过TweenLite、TweenMax的人还有么?
4、显示对象的对齐
显示对象在下载后有个比较恼人的问题,就是定位和对齐。这个问题其实已经被TransformManager 很好的解决掉了。LoaderMax只是让操作更简单了。
只需在初始对象的属性里面增加width,heighth或scaleX,scaleY(前者优先权大于后者)再配合scaleModes属性就很轻松了。
5、选择性打包
实际上LoaderMax并不是一个万能下载器,他只是一个壳儿,具体的下载交给SWFLoader,XMLLoader,MP3Loader...等等,这样的话,项目中要啥就选啥,可以节约文件大小。编译的时候也不会浪费不必要的时间。
6、并行下载
一般的下载队列,就是逐个下载吧?LoaderMax有个maxConnections 属性,可以设置同时下载数。默认为2。
7、下载信息
还有件比较烦人的事情,就是在定义一个loader后,有时候还要再为之定义个变量,指向下载对象。该指向还必须得在下载好以后才能设置。
这点LoaderMax也封装掉了。LoaderMax.getContent(),而且由于Loader事先就是有类型信息的,像CSSLoader,MP3Loader,所以content在使用上有着很高的可读性。
还有很多,诸如下载流程控制、优先权设置、Loader嵌套性、XML驱动配置、Flex友好等很多特性。有兴趣的自己玩吧。
[/size]
greensock又出重量级产品 - LoaderMax
原创
©著作权归作者所有:来自51CTO博客作者ch_kexin的原创作品,请联系作者获取转载授权,否则将追究法律责任
上一篇:LoaderMax 1.5 介绍
下一篇:JSFL 非官方不完全手册
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
产品分支管理与团队协作
产品分支管理与团队协作
分支管理 迭代 团队协作