實戰iOS應用從32位升級到64位

標籤：64位   ios   

      蘋果官方會在2015年2月1日不允許不支援arm64的應用的提交，這對我們這種開發行動裝置 App產品的人來說是一把達摩克利斯之劍。我前面寫過一篇文章《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位真機，必須進行壓力測試。

實戰iOS應用從32位升級到64位