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的图片。
