当前位置: > > > AS手机项目 - iphone,android实机测试的经验总结

AS手机项目 - iphone,android实机测试的经验总结

Adobe Flash Builder提供了测试用的模拟器,供没有足够设备或希望快速测试的开发者使用。
然而众所周知,实机测试是flash或flex移动开发中绝对不可或缺的一个环节。

本文将提出一些Android及IOS实机测试与模拟器测试的区别,
便于开发者了解有哪些问题必须实机才能测出,并根据这些来在恰当的时间进行实机测试,以避免项目回滚。

1,IOS不支持Loader.load(swf)
我们可以通过将若干文件与主swf打成一包,通过运行时动态加载来减少主swf体积和运行时内存。
但在IOS上调用loader.load(swf)是无效的
Air for IOS的作用机理与Air for Android不同,前者将AS的abc字节码转换成IOS能识别的字节码形式,也因此失去了AVM虚拟机的特性。
可以在安卓上正常使用loader.load(swf),而IOS上只好将全部代码打成一包,仅将纹理放在外面,使用loader.load(png)的办法来节约内存。
需要注意的是,在IOS设备上测试时,如果选择“快速打包”将可以支持loader.load。“快速打包”使用的思路仍是虚拟机思路,不过截止目前,实际发布版本不能支持

2,虚拟机测不出SharedObject
虚拟机被关闭后再打开时,SharedObject不会被保存,这不代表实机也不能进行存档。

3,虚拟机使用的内存与实机相差巨大
对同一个项目,在ipad3上的privateMemory只有18M,而我的虚拟机显示System.privateMemory达到了88M

4,Air for IOS不能用主动退出
NativeApplication.nativeApplication.exit();在模拟器和安卓上可以使用,但是无法在IOS上使用。
此外,在IOS上Air程序进入后台运行声音无效,
而在Android上Air程序进入后台运行还有声音。

5,Stage3D(Starling)显示对象数量
如果在ipad上运行,请将starling显示对象控制在700个以下(24~30fps)
starling因为使用显卡,在显示对象数量达到上限前和达到上限后性能有本质的区别,且无法从cpu占用中明显看出当前是否达到数量上限。(可能会注意到cpu占用10%,而显卡风扇转动非常厉害)
一般PC机上可同时支持900个左右starling显示对象,在ipad上控制在700以下最佳。
与传统2D渲染不同的是,对starling显示对象的尺寸无需加以限制,渲染30x30的元件和300x300的元件上限数量所差无几。
如果面向ipad3开发,并且使用了高分辨率(2048x),那么数量还要酌量减少。
(由Starling1.2公布的官方数据,Starling1.1能在iPad1上支持满帧频的显示对象数量限制为690个,与此贴测试结果相似,Starling1.2的测试数据是1080个)

6,Stage3D(Starling)的基本渲染可能在安卓系统下超负荷
因starling每帧都要调用render渲染,这是一个基本的开销
某些屏幕很大或cpu较差的安卓设备甚至无法支持30fps下Starling的基本开销,而一直拖帧到28或者25
这样的帧频在用户看来并不算很卡,但在安卓实机上长期保持这种“亚健康”帧频是危险的。
因为这个帧频是GPU(含集成GPU)消化不了starling提供数据造成的,
很快你会发现安卓机开始很热。无论从电池消耗、机器寿命还是用户感觉上,必须提前避免造成这种情况。

7,帧频稳定性
无论安卓还是IOS,Air的帧频均不稳定,即使是ipad3,两次getTimer间隔也会较大幅度跳跃。
如果你在使用getTimer确认帧频来判断是否出现拖帧,
那么尽量使用1秒内getTimer间隔的平均数据。监听两次getTimer之间的最大时间间隔是没有太大意义的。

8,关于renderMode="gpu"
如果放弃使用stage3D,那么在苹果机上将renderMode设置为gpu可以得到较高加速
这种加速主要针对alpha渐变、rotation渐变、scaleX或scaleY渐变等。
在这个模式下滤镜将全部被删除,而画面质量也会低到LOW的水准,能看出锯齿。
整体看,除了能立刻将已有swf在苹果上较高效率运行外,这个模式的画面质量、效率、扩展性均不如stage3D
然而,这种加速方式对安卓不适用,你会发现在安卓上renderMode="gpu"比传统的cpu渲染更让人郁闷。

9,关于stage.fullScreenWidth和stage.fullScreenHeight
笔者认为这是Air3.3和更早版本的bug,
当设置项目为横屏时,在模拟器中仍然得到了纵屏才有的宽高,而在实机上正常。

10,移动设备内存不足问题
这条在很长时间内困扰着我的开发,将专门花点笔墨来分析。
众所周知,将多张纹理碎片集中到一个大型纹理上(Sprite Sheet),能节约文件体积,加快渲染速度
同样众所周知,Air运行时首先会先将自己整个载入内存。
那么,某项目有两张2048x2048纹理(2M),
如果使用Embed嵌入文件的办法,算上声音,主文件体积大概在10M左右。
开始运行后,算上Air运行时以及基本的内存使用,privateMemory可以达到30M。
一旦将纹理从png转换为BitmapData无压缩格式时,内存占用将会暴涨,如果不及时释放,两张解压后的位图就能使内存暴涨到将近60M。
以iPad1为例,iPad1的物理内存是256M。
有人说这就够用了,我们采用60M。那么后面我们来切蛋糕,看看到底我们能分到多少。
首先,其中将近一半128M被划分给集成显卡,也就是充当显存使用了。剩下的40M以上被操作系统占用去。再剩下的10M要给输入法以及其它常驻软件、服务。
因此,即使用户没有再运行任何东西,我们的内存只是“勉强够用”,在苹果的内存释放机制下,很可能因申请不到整块内存而莫名其妙闪退。
解决办法在于利用128M的显存。宁可牺牲一部分效率也要将单张纹理缩小,避免解压时闪退。每解压一张图片并上传给显存后立刻调用System.gc(),移动设备上始终可以使用System.gc()。

11,打开程序加载时间
移动设备上打开程序的加载时间明显慢于模拟器
这取决于主类构造方法逻辑是否复杂。
在IOS上,应用会优先加载Default.png充当loading画面,用户可以等待更多时间,
但在Android上没有loading画面,如果在开始过程中加载了大量声音、图片等,应在它们之前至少为用户提供一张loading的图片。
评论0