在苹果推出iPhone5S时，64位的应用就走到了眼前。当时就看见苹果官方资料宣布iOS7.x的SDK支持了64位的应用，而且内置的应用都已经是64位。

我记得自己刚刚接触电脑时还有16位的系统，指针的寻址范围还是16位的。当年用TurboC时，还要根据应用的大小选择是tiny模式还是其他。后来很长一段时间使用32位的模型编程，4G是牢牢记住的一个边界条件。而现在，64位走到了眼前。

就如同16位转向32位一样，硬件肯定是最先推出的，SDK也会跟进，然后各种第三方的应用才会逐步跟进，这个过程一般都需要持续一段时间。这次苹果在推出之后，很长一阵子也处于32位和64位并行的过渡期，但是，随着10月份苹果宣布，2015年2月1日起，上传AppStore的应用都需要支持ARM64了，具体消息请猛戳这里。

于是开始看了一下32位应用如何转成64位应用

1. 基础知识

Xcode 5.0.1开始支持编译32-bit和64-bit的Binary

同时支持32-bit和64-bit，我们需要选择的minimum deployment target为 iOS 5.1.1

64-bit的Binary必须运行在支持64-bit的CPU上，并且最小的OS版本要求是 7.0.3

2. 让应用兼容64位的基本步骤

安装Xcode5.0.1或者以后——其实现在能提交AppStore的Xcode版本最少也要5.1.1

在Xcode中打开工程，编译，修正错误以及警告，尤其是针对32位和64

在Project Setting里面，把最小应用使用的SDK改到5.1.1或者更高的版本

把Architectures参数设置成“Standard Architectures (including 64-bit).”

这样你的应用就支持了64位的CPU，再次修复编译器的错误和警告，请注意，有些问题编译器是没有警告的

在64位的真机上测试你的应用

使用Instruments查看内存使用的状况

3. 从32位到64位的变化

3.1 数据类型的变化

这里主要是语言内置类型所占的字节数以及字节对齐的不同。在32位的年代，使用的是IPL32的规范，到了64位之后，改成了LP64规范。

除了这些以外，还有浮点类型

数据类型里面，NSInteger在32位时等同于int，在64位时等同于long，而这个数据结构使用很广，很多不规范的时候会直接和int替换使用，在32位是毫无问题，但在64位时，这就是隐患了。CGFloat也有同样的问题，所以代码的检查修改必须仔细。

至于对齐，如果使用了偏移量来访问struct的项，那么需要认真仔细的检查，其余的还算好，当然如果你用了malloc，那么也请检查一下分配的内存大小，建议是多使用sizeof来帮助计算。

还有，针对存储的文件，比如存储在iCloud上的文件，你无法确定是一个32位应用还是64位的应用会去访问，那么请一定把数据内容的解释写成一模一样。

3.2 方法调用上的变化

64位应用要求所有函数都有原型，这本身就是一个好的编码习惯

函数的造型必须和原型完全一致，尤其要避免参数个数未定的函数指针造型（printf一类）

在64位系统在运行时调用函数和32位系统是不同的。主要的区别在于传递具有可变参数个数的函数的参数时，我们来看下面的代码：

第一个函数是固定传入2个参数，第二个函数是参数个数不定的，在使用中，也传入了2个参数。在32位系统下，这两个函数的参数传递是非常类似的，而在64位系统下，这两者就是截然不同了。

3.3 汇编的不同

因为是不同的指令集，汇编当然会不同。不过我们一般的应用不会用到汇编，所以这一项比较少遇到。

4. 第三方库

最后，我们项目中使用的第三方库肯定需要支持64位系统，否则还是白搭。所以大家在升级时需要检查自己使用的第三方的库，看是否已经有64位的版本出现了。

苹果目前的系统中（iOS7/iOS8）,32位的framework和64位的framework是共存的，所以如果所有的应用都是64位的话，系统就自动不加载32位的framework，这样可以少占用资源，另外对运行的速度是有好处的，也就是说，你会感觉手机运行的快了一点。

应用在兼容64位系统后，内存的占用肯定会变多一点，不过性能也有相应的提升。