[AIR for Android]AIR项目个人技术总结

(提示:以下观点仅仅代表我现在的个人，有谬误请指出)

项目详情

游戏类型：

• ARPG 仙侠类大型多人在线手游，目前android版本已上线 IOS版随后跟进，虽然IOS版本即将上 但是到现在能说的东西很多 所以尽量把想说的写出来。一来是备忘 二来是分享  其实主要是备忘 我是一个健忘症患者。

项目框架和开源技术等：

• AIR+STARLING+FEATHERS+ALCHEMY

ANE本地拓展的使用：

• 除了zrong的部分功能之外 我个人还加了很多小功能大功能，例如原生解压 项目重启 等。ANE是AIR项目中很大的一个技术点。可以说仅此于素材处理 网络处理 内存优化 。
• 素材处理 网络优化 内存优化 本地拓展 是我认为在一个AIR移动项目中比较主要的技术难点，当然仅仅是目前我的经验来下的偏论，而我在项目中参与比较多的其实 只是 素材处理 和 本地拓展（ANE）.

素材处理和工具使用：

• TEXTUREPACKER，ATFTool，后面是自己写的 图片压缩工具 割图工具  打包工具 纹理批量处理工具  等（工具和效率挂钩 在这过程中我深深的认识到这一点）

分散总结

首先对于AIR引擎：

• 关于我与AIR：接触AIR有一年的时间了  与它的各种博弈过程 耗尽了脑汁，AIR或者说框架 其实就是一个虚拟机，再细化一点 其实就是一层在android虚拟机上的一层膜，仔细想一下  对于安卓设备：UNIX 内核-android虚拟机-AIR虚拟机-项目，知道这层关系后，对于AIR 比原生慢； AIR优化没原生好 ；AIR性能缺陷什么的 其实都是天生的。我们能做的只是改变AIR的运势 而AIR的命途终究要靠ADOBE自己改变。（我的理解  人的一生存在命运  命运 = 命+运，命就是先天的无法改变 就像你无法改变的出生一样。运 则是可以改变并且会对命产生影响的。但是命终归无法撼动。人生哲学就讨论到这里）。
• AIR本身固有的限定条件：

1. android2.2 CPU ARMv7以上
2. 运行时大小固定，

前段时间经过对android系统的了解和android逆向的一些研究。发现其实android在2.2以后才加入的JIT（just In Time）技术，而AS3恰恰是建立在JIT即时编译的基础上的语言。而对于APK包的大小上，在AIR runtime更新的同时 runtime.apk的体积也越来越大 从开始的7m到现在的9M 未来超过10M也很正常。而10M被认为现在移动应用的一个跨度，一个游戏或者应用每增加10M 则转化率 用户下载量在同样的广告位上 会下降一个级别。因为不是每家开发商都是盛大 能把《亚瑟王》这种几百M的游戏砸成现在这样。所以经常会听到老大埋怨怎么内存还没下去？ 怎么打电话就死机？ 怎么低端机不能玩我们游戏？怎么最新版的android也不能玩我们游戏？等等此类的问题。而这类问题几乎都不是由于代码导致的  代码的内存泄漏 代码的逻辑错误 可以在慢慢中解决。也就是说选择AIR  其实就给我们自身的项目定了一个标准：我们走的高端路线，拿着华强北那堆破山寨android机的高富帅们建议绕道。

其次关于android本身：

• 设备适配：在国内山寨横行的大环境下，没有什么分辨率是不存在的。就目前我拿到的数据来说，前20名就出现了不少奇怪的分辨率~所以对于android项目 分辨率设备适配是一项艰巨而漫长的工作。要保证游戏在各种android手机上都显示满屏 按钮都在那个位置，并且不同设备都适应，偶尔发现的事情就是某玩家的设备玩我们游戏界面关闭按钮看不到了。所以其实并不是单单取fullWidth fullHeight那么简单。

（排名前20的android2.2以上的设备分辨率）

1. 对于这个设备适配 项目做法是 把主UI的部分坐标栅格化直接用0-1来代替具体的数字；
2. 假设一个分辨率例如480*800, 把界面建立在这个分辨率之上  遇到不同的再调整。或者乘以一个参数例如  (width/800，height/480)；

• 移动网络：无可厚非的一点就是，虽然我们身边的人全部用WIFI 几乎看不到人用GPRS来玩网游这种高流量消耗的游戏了（挂QQ除外），但是其实还是有很多的人使用3G 2G来玩游戏  甚至是下载几百M的游戏 都是用流量来下载 而非WIFI。这就对游戏本身的网络优化有很大要求。稍微不注意 过久不响应 游戏就掉线。因此客服应对这堆玩家的吐槽已经形成了免疫。试想一下用手机卡的流量来玩大型多人在线网游 是多么可怕的事情  打一帮战如果流量超出的话 明天一看提示停机了 可见运营商多么的赚钱。目前我的统计数据中有25-30%左右的是非WIFI的用户。
• 内存限制：对于AIR项目来说 一加载进来就已经开始占内存了，之前也说过 我们的AIR项目是运行在AIR运行时之上的。一个AIR运行时就占9M，我并没有具体去算过单纯的加一个运行时所具体占的内存大小。但是肯定对于原生的来说 已经多了一层。而其实很多很多的山寨机 内存都不足512M。如果再挂个QQ 开个360 开个陌陌 开着微博 再玩我们的游戏。那512已经早早用完了。(当然 如果假设每一个玩家在玩游戏之前 都关掉QQ关掉360关掉陌陌关掉微博关掉一切占用内存的东西 那512肯定够用)。所以我才在开头把内存优化作为整个项目的技术难点来定位，当然这仅仅是我个人带有情绪的偏论。
• APK签名：其实这只是一个很小的问题 之所以拿出来说 是因为我在这上面犯过错误。我曾经把好几个大平台的APK在签名冲突的情况下更新到玩家手上。这件事情是我参与项目以来犯的最大的错误。事情是这样的。由于AIR打包的APK 的主activity的launchMode是singleTask。这种launchMode的activity在栈堆中位置比较独特。在切换到桌面再切换回来的时候 总是选择launchMode为singleTask的activity显示。这就导致了一个问题。玩家在支付的时候打开SDK的activity 然后退出桌面看验证短信 然后切换回来  支付界面已经消失（其实是activity栈堆中但凡在singleTask之上的全部被切掉）。这个问题的解决方式我后面经过修改adt打包工具才彻底解决 但是在前期通过反编译来修改的时候恰恰引发了这个错误。由于FB打包APK 是签名A，反编译APK在编译是签名B 导致了冲突。而这个冲突在测试同事那里也没被发现 就已经更新到玩家手中了。就目前来说 我知道UC 小米 等很多平台都会在拿到APK之后自己再签名才更新到平台上 。所以这就要求有自动升级的APK必须做好签名的一致性。例如我现在的做法就是: 把APK给平台签名后>>再拿回来 再更新到服务器>> 再升级到玩家手中。

关于Starling和feathers：

• Starling，目前我项目的版本还是1.2.一来当初没有人手再去研究升级后的starling，二来本身已经对starling做了很大的改变，几乎把渲染的核心部分都改了，所以如果我提出的问题在你用的starling已经得到改善了的话 请无视。所以看着性能还行就继续用下去了。事实就是这样  不可能通过等待它的升级来给自己项目带来改观。开源的项目最大的优点就是我们都可以随便修改它而没有侵权问题。不得不说的就是  其实开源是我的信仰。
• feathers，其实这就是一套UI框架。用它之前犹豫了一段时间 但是到最后主程同事还是选择了它，他可能从更多的原因考虑，而我的原因也是这个 由于它开源。一般开源的东西都有一个特点。首先代码很值得一读。其次作者的技术观肯定是“分享是我的快乐源泉”；

关于本地拓展（也就是臭名昭彰的ANE）

• 关于ANE 很多人吐槽它 其实它很可怜，网上几乎所有的ANE教程 开头都是先吐槽几句，第一句骂下ADOBE 第二句骂下android或者IOS 第三句再骂下会但是不教我在装B的人。最后再低下头继续。对于我而言其实它还是很可爱的。虽然很多大神都在吐槽它。而我把我遇到的问题全部写了出来 并分享 详细请看 教程传送门 源码传送门。ANE的确是AIR移动项目必须要跨越的技术之一。它要求你最理想的状态下是 懂一点JAVA 再懂一点OC 再懂一点C/C++ ，因为有些SDK还调用了SO源码库。懂一点反编译，懂一点反汇编，最好还懂一点逆向。如果再懂一点源码重构 和 最少能读懂JAVA反汇编。那我的天啊 ANE对于你简直和HELLO WORLD差不多。最后如果你是主程负责分配工作 最好把ANE的这个大难题分给一个耐心且低调的码农。
• 关于平台对接，多平台对接其实是一个必不可少的事情，当今的手游联运已经成为趋势。而且现在国内平台似乎比开发团队还多，我认识的一个平台商 平台SDK客户端和服务端都是外包的。所以这就形成了项目开发商对项目运营商这种一对多的关系。其实平台方也是一对多 只是他们的多是我们的同行，我们的多也是他们的同行，平台对接中把对方的SDK写成ANE是必经的步骤 当然也有类似UC 等提供ANE的 就目前来说 80%的小平台都不提供ANE  还有很多很多在对接之前你都没听过的平台。所以对于一款AIR的游戏多平台的管理 是一项非常麻烦的工作。而这项工作又和ANE交叉 而且分不开 必须同一个人去管。当然如果你的项目组有一群全方位技术都牛爆了的人  那随意了。

以上是我的部分理解和观点 后来还会更新 部分言论充满了个人情绪  如果你有不同观点 请发表我们共同探讨