实战iOS应用从32位升级到64位

      苹果官方会在2015年2月1日不允许不支持arm64的应用的提交，这对我们这种开发移动应用产品的人来说是一把达摩克利斯之剑。我前面写过一篇文章《iOS上应用如何兼容32位系统和64位系统》，但那还是纸上谈兵阶段，没有进入实战。到2015年1月份，我终于在应用提交了一次新的稳定版本后，开始进行应用的arm64升级。

      1. 准备

      我们的应用是多媒体的播放器，牵涉到了ffmpeg/SDL等著名的开源第三方。因为项目中并非把这些项目的源码直接引入，而是通过打库链接到项目的方式来使用，那么所有的第三方的库都需要使用支持arm64的库。

      如果你不能确定库是否支持了arm64，可以在cmd模式下用file命令来检查一下库文件。

      测试的真机，包括32位的设备和64位的设备。

      2. 增加arm64的architecture

      这个没什么说的，在项目Build Settings页面下Architectures和Valid Architectures两个设置项都设置成${ARCHS_STANDARD} 即可。

      这里有一个细节提一下，在Xcode5中，${ARCHS_STANDARD}是指armv7，armv7s和arm64；而在Xcode6中，${ARCHS_STANDARD}是指armv7，arm64，其中armv7s被苹果抛弃了。

      《Xcode 6 drops armv7s》这篇文章详细讲述了这一点。

      

      3. 实际中需要注意的几个地方

      I）汇编代码

      如果你有汇编语言的源码，那么是件比较让人头疼的事情。因为32位架构和64位架构有及其巨大的区别，根本不可能混用代码。而一般使用汇编语言的地方都是很重要的核心部分，这种情况遇到只能具体问题具体分析了。

      II）sizeof

      我在代码中是比较喜欢是使用sizeof的，因为感觉会比较容易移植，系统会自动帮我们计算具体的大小，而不用自己手动一一计算。但这次sizeof还是带来了一定问题的。

      我遇到的场景是我的应用需要和一个硬件设备有一定的数据交互，会互相发送命令。这个硬件设备是独立于应用程序的，显然，我需要保证和硬件的命令内容的接收、发送和处理都是严格按照以前定下的协议工作的。但32位和64位对于一些类型的解释长度是不同的，这样就会带入一些问题。最典型的类型是long，size_t和指针，最后要兼容真的花了一番功夫。

      其实，还有一个场景这个问题也很明显——云上的内容，因为云上的内容无法确定下一个访问的是32位应用还是64位应用，所以同样会遇到这些困难。

      总结起来看呢，在要求数据结构在32位和64位下要解释一样的场景下，使用就要小心了，尤其是malloc(sizeof(x))这种使用方法。

      III）指针和整数的互换

      这个恶劣的先例是microsoft率先开启的，在win32下官方代码都充斥这样的指针和int互相转型，当时的逻辑是因为都是4个bytes的，所以内容没有任何损失，这个做法是安全的。

      时过境迁，这样的代码在现在就结出恶果了，如果你代码中留存着这样的技巧写出来的内容，那么，你就一面诅咒microsoft一面自行修改吧，^_^

      IV）恶劣而随意的代码

      比如：int和NSInteger不区分，unsigned int和NSUInteger不区分等等，一些写代码不太严谨的程序员，真的是充斥着这样的代码，这两个例子在32位中运行是没有问题的，所以真的是不难看到，但是，64位下不是这样的，以前很随意的代码，现在都要付代价了。

      剩下还有一些诸如format的问题，函数必须有声明等等的问题，这些在实际升级过程中倒是没有带来太大的麻烦（当然，这可能和我应用的类型相关）。我遇到的最大的麻烦是以上列举的4点。

      最后，这样升级的应用要进行足够的测试，包括32位真机和64位真机，必须进行压力测试。