光荣在于平淡,艰巨在于漫长
致力于DAsm+C,MASM
继前一篇介绍了android编译aapt的工具之后,可能会困惑我为什么会花一大篇文章去写一个工具怎么用,在这第二篇文章我就详细分析 ADT是怎么使用aapt来编译android资源的.
我们用原生语言java编写android程序的时候,我们仅仅需要负责编写代码 配置权限参数的工作,而编译资源 编译代码 打包apk 全部交给eclipse或者交给androidSDK的工具代劳,同样我们编写AIR for android程序也是如此 我们仅仅编写代码 其他工作都一般交给FB代劳,而FB又交给ADT代劳,而ADT则指挥android SDK的各种工具工作,这编译资源 便是 从 完成代码之后的第一步工作.下面我们看看ADT是如此操作aapt实现编译android资源的.
接触AIR将近有一年的时间,这一年里遇到很多很多的问题,从AIR FOR ANDROID 的APK签名错误,到ANE的适应所有调用原生,再到APK的加密解密反编译,然后是跨IOS/ANDROID 一路伴随AIR走来,AIR从3.4到现在的4.0,应该说见证了一些东西的发生与过程.一直以来希望找一个切入点 而形成一系列的分析文章,刚好今天临下班前突然奇想,其实我可以从分析AIR的打包工具ADT开始.于是萌发了写这篇(如果有后续的话 包括后续)文章的想法,现在第一篇我想把aapt这个工具的使用详细分析.并最终给出在写ANE过程中困扰我已久的最有效资源处理方式.
PS:为什么我会从一个工具开始说,因为ADT就像汽车一样,而aapt则是ADT的后轮的轮胎中的打气孔
最近研究Flascc顺道应用到AIR for IOS项目中，发现Flascc编译的优化等级与打包IPA有着非常大的关系
首先是一个老外先发现的：传送门
先说说AIR for IOS打包，打包限制发行版和发行版 官方文档说需要多一点时间，其实那里止需要多一点时间啊，除了时间需要多一点以外（4G内存版MAC 需要15分钟以上），还需要配置64位的机子 4G以上内存，32位的别想打包IPA顺畅了（注意 是顺畅 不是不能），翻看JAVA虚拟机LVM官方解释是 32位的虚拟机限制到1.5G的内存，而64位的JDK则不限制内存，而AIR 打包IPA的时候虚拟机内存一路飙升，我一开始使用32位+4G内存打包的时候 打开内存查看器看到java.exe所占内存一路高歌 直到爆掉。不禁让人唏嘘，请问adobe打包个ipa要那么多内存干什么？
一直就有朋友问我手上有没中国游戏移动基地的ANE,假期末几天有点空余,于是就update了….
在写这个ANE的过程中我深深的感受到了他的奇葩.简直把技术用到了极致,中国移动基地的SDK开发客户端现在应该为自己写出那么艰苦卓绝,那么奇形怪状,那么神来之笔,那么旋风无极,那么宇宙超级无敌屌炸天的SDK而暗暗庆幸吧.
对于这个SDK的奇怪程度足以详细写一篇博客来细细阐述.
(PS:严重提醒适用这个ANE的AIR开发者,请从SDK文档 到 我写的README 每一字每一句都仔细阅读,特别是对于我写的README)
对于AIR项目的签名类型 无论是android 还是IOS。似乎大家都只知道是.p12 也就是PKCS12类型，很多人都苦恼怎么签名和原生开发的不一样（主要是针对android）。一般android原生开发是使用JKS也就是 .keystore文件来签名。我一直以来想研究出用.p12签名文件转换成.keystor文件的方法。但是很抱歉。从.p12文件转到.keystore会缺少密匙链。当然反方向转换没什么问题。
在AIR手机游戏联合运营的今天。充斥着各种平台的签名 繁杂而讨厌。很多时候如果APK或者IPA需要自己做后台服务器更新的话 还需要去找运营商签名。严重影响更新进度。当然让运营商提供.keystore文件也可以。但是很多人只知道AIR打包只能用.p12文件签名。而使用.keystore文件似乎只有走 打包好APK再重新签的方式。其实不然。p12文件的签名方式 只是FB上限制的。在adt中已经提供了所有签名方式：
首先我很讨厌svn。讨厌到不能再讨厌它了。虽然我在团队里面负责配置svn 服务器 客户端 负责每一个人的svn帐号，负责整个版本管理。我一直在问自己为什么不改用git呢。关于git的好处我可以说一上午，但是无论我说再多，用惯了svn的同事们还是无屑一顾。因为关于他们认为svn的好处 他们也可以说一上午，虽然我认为与git相比简直不值一提。
而我现在要做的是在MAC中配置SVN客户端环境
首先检查本机svn版本 发现是 1.6。
[code lang=”java”]
svn –version
[/code]
而我svn服务器我当初记得配置的是1.7以上的。按照以往给同事配svn的经验 mac上的svn必须更新。否则肯定没戏。事实验证也是如此：
[code lang=”java”]
svn checkout https://xxx.xxx.xxx.xxx/svn/myproject
–username=rect –password=123 /user/rect/myproject
[/code]
自然报出svn版本过低的问题，于是乎只能升级svn了。
各自的解决方式本身没什么问题。问题在于svn版本的改变。
在ios中程序间互相调用可以通过url来解决。在oc里面直接在函数handleOpenURL 便可，但是在ane中就没那么简单了。下面详细介绍下air项目中url的设置和使用，使用支付宝快捷支付ane作为例子。网上有稀稀疏疏的几篇文章偶尔提及,但是并没有完全给出一个DEMO来.
在此之前请详细阅读官方文档：传送门
关于打开URL的ANE例子:传送门
IOS里OC的处理方式:传送门
在AIR中配置URL供其他程序调用
1.首先需要在-app.xml中加入如下配置:([IPHONE]标签中)
[code lang=”java”]
<iPhone>
<InfoAdditions><![CDATA[
<key>UIDeviceFamily</key>
<array>
<string>1</string>
<string>2</string>
</array>
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>AlipayANE</string>
</array>
<key>CFBundleURLName</key>
<string>com.rect.app</string>
</dict>
</array>
]]></InfoAdditions>
<requestedDisplayResolution>high</requestedDisplayResolution>
</iPhone>
[/code]
在这类配置了一个Name为”com.rect.app”的Schemes.调用方式为”AlipayANE://”;
这几天更新APK 从版本v1.2升级到版本v1.3.遇到的签名冲突问题.在这里做一个记录.
A,B,C三个APK中 按照逻辑上将 A,C是应该拥有共同的签名key_A的,所以可以正常升级不会出现签名冲突;
但是事情就是这样发生了,当我安装APK_A之后安装APK_C 提示签名冲突;
关于UC的ANE我已经改动很多次了。为了适应Starling的GPU渲染项目（-app.xml中的direct），从登录界面的横竖屏到支付界面的消失 再到悬浮的BUG 一路过来总是那么苛刻。前几天发版本，UC审核人员又把悬浮的问题拿出来说，忍无可忍，没办法只好再次对UC ANE进行修改。这次改动后，悬浮BUG会彻底解决。首先把在接UC SDK过程中遇到的问题先复述一遍：
UC 与AIR项目兼容性BUG：
把悬浮中插入自定义activity的实现：
关于UC悬浮与Starling项目的兼容性BUG重现：
限定环境：AIR+Starling+横屏
一直就有朋友问我手上有没支付宝的ANE,假期末几天有点空余,于是就update了….
支付宝本身提供了内支付的SDK,只是相比于其他的SDK支付更加简明而要
没有悬浮等一大堆干扰游戏的玩意儿,接支付宝SDK真是一个明智的选择.
PS:写的ANE for IOS 并不多,目前不太确定是否有问题.若要用还是需要根据自身情况而改动.
(可任意转载传播 但请注明出处)