蘋果發布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中打開project。編譯。修正錯誤以及警告，尤其是針對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位系統是不同的。基本的差別在於傳遞具有可變參數個數的函數的參數時，我們來看以下的代碼：
int fixedFunction(int a, int b);
int variadicFunction(int a, ...);
int main
{
int value2 = fixedFunction(5,5);
int value1 = variadicFunction(5,5);
}
第一個函數是固定傳入2個參數，第二個函數是參數個數不定的。在使用中，也傳入了2個參數。在32位系統下，這兩個函數的參數傳遞是很類似的，而在64位系統下，這兩者就是截然不同了。
3.3 匯編的不同
由於是不同的指令集。匯編當然會不同。只是我們一般的應用不會用到匯編，所以這一項比較少遇到。
4. 第三方庫
最后。我們項目中使用的第三方庫肯定須要支持64位系統。否則還是白搭。
所以大家在升級時須要檢查自己使用的第三方的庫。看是否已經有64位的版本號出現了。
蘋果眼下的系統中（iOS7/iOS8）,32位的framework和64位的framework是共存的，所以假設全部的應用都是64位的話，系統就自己主動不載入32位的framework，這樣能夠少占用資源，另外對執行的速度是有優點的。也就是說。你會感覺手機執行的快了一點。
應用在兼容64位系統后，內存的占用肯定會變多一點，只是性能也有對應的提升。
版權聲明：本文博主原創文章，博客，未經同意不得轉載。