最近准备打包新版本游戏上传到appstore,结果提交时提示我必须编译支持arm64版本的应用包才能上传,本来还以为这个和iOS一样,改一下编译选项,提升一下最低版本号就差不多了,结果事实证明我还是图样,因为cocos2d-x对于xcode来说就是一个无比庞大的第三方库.连着弄了一个通宵和俩工作日才算勉强搞定,记录一下遇到的坑.

###引擎版本

之前的引擎版本是2.1.5,还引了很多莫名其妙的第三方静态库(还都是系统有的,png啊,jpeg啊,xml之类的).猜想是之前的项目人员为了和安卓统一管理所以引了一大堆静态库文件, 通通报错.照网上方法,下载了这些类库对应的64位版本下来,没想到弄了大半宿,还是各种莫名其妙的报错,好气啊.然后看到官网有支持arm64的2.2.6版本的cocos2d-x版本提供下载,考虑到2.2.6和2.1.5之间的差异性比较小,果断直接下载下来,引入第三方库,改掉一些之前引擎里面自己改掉的地方,反而比之前折腾2.1.5花的时间少.然后编译终于成功了,也看到界面了,本来欣喜之下觉得没啥大问题了,当然被瞬间打脸了.

###C/C++代码

在此先贴2个链接,对于解决这方面问题很有帮助.

首先是 苹果官方的文档

然后是iOS工程如何支持64-bit 这篇博文

不得不说,像cocos2d-x项目,尤其是我现在做这个,由于曾经有项目人员是win32出身的,项目里有大量c/c++系统库函数时,在编译arm64时更加蛋疼,如果一些数据上的操作全部使用cocos2d-x的array和dictionary的话,会麻烦点,也会踩坑,不过在升级时跟着引擎走,也不会有这么大岔子(不过做cocos2d-x的同学们都吐槽过的一点就是升级引擎基本等于重写代码,这点就不吐槽了).

直接说几个我认为比较重要的结论吧.

永远不要使用malloc去为变量申请特定内存的大小

注意所有指针操作的地方

基本遇到的问题都可以归结在上面.

场景1:有个业务代码里,使用了一个CCLayer**作为容器,通过malloc来申请内存,使用memset来清零做初始化操作.结果发现arm64编译下,初始化之后容器内有几个元素竟然不是NULL,导致之后的操作中判断与赋值出现各种奇怪问题,从逻辑上看,一点问题也没,正好我看那段代码早就不爽了,同时也是不理解一个容器为什么要用CCLayer**,直接将其改成vector实现,顿时神清气爽,也没问题了.

场景2:在一些数值计算的地方,由于数据类型不一样,对齐方法也有变化,对照官方给出的图片,在一些对一块内存地址做清0,写入,copy操作时,计算结果不对,最奇怪的是我参照网上写了好几种memset,memcpy的实现,每种调用得出的结果竟然都不一样,当时有种崩溃的冲动,因为出问题的地方是md5,而且手写memset和memcpy这些系统函数总感觉怪怪的,总不可能所有调过系统函数的地方都重新引用成自己的实现吧,而且网上也没看到和我一样类似的问题,就先去github找了个没有使用memset和malloc的md5实现来,测试下果然没问题,遂使用宏判断来区分Android和iOS来使用不同的方式md5,解决之.不过这中间过程算给了我一个警告,看来之后要再去好好看看C/C++了,知道原理有助于更好更快地定位问题

###分辨率 这个相对之前2个就是开胃小菜了,使用arm64编译之后,在iPhone6和iPhone6 plus获取屏幕尺寸,会得到他们真实的尺寸,(之前和iPhone5一样是1136x640),所以在适配策略上需要针对他们的分辨率做调整,我是取的两种设备的宽度来判断的,6 Plus是 2208,6是1334

目前基本就遇到了这些问题,暂且记录一下.等完全搞定malloc和memset的问题,再来update.