眾所周知，蘋果是從iPhone 5s開始對全線移動產品使用64位架構，那麼如果App需要相容32位和64位的機型，就需要注意它們之間的區別。

  下面我們首先看看基本資料型別的區別：

32位編譯器

char ：1個位元組

char*（即指標變數）: 4個位元組（32位的定址空間是2^32, 即32個bit，也就是4個位元組。同理64位編譯器）

short int : 2個位元組

int：  4個位元組

unsigned int : 4個位元組

float:  4個位元組

double:   8個位元組

long:   4個位元組

long long:  8個位元組

unsigned long:  4個位元組

64位編譯器

char ：1個位元組

char*(即指標變數): 8個位元組

short int : 2個位元組

int：  4個位元組

unsigned int : 4個位元組

float:  4個位元組

double:   8個位元組

long:   8個位元組

long long:  8個位元組

從上面的比較我們可以看的出來，對於32位的機器來說，long是四個位元組，而對於64位機器的long是8位元組，如果在專案開發過程中忽略了這個點，很容易出現問題。下面舉例分析：

   在我們的專案中，有這樣的需求，伺服器端返回一個時間戳，單位為毫秒，客戶端需要解析該欄位並轉化為NSDate，儲存到資料庫中。對64位的機器我們只需要定義一個欄位，比如startTime，型別為long，解析欄位可以使用objectForKey的longValue獲取到時間戳，然後轉換為時間型別，沒有任何問題。但是在32位，我們發現轉換後的時間型別是錯誤的，型別1970...。究其原因，就是因為32位機器上毫秒級的時間戳longValue後越界，導致後續轉換都異常。解決這類問題的方法是在涉及到時間戳為毫秒的情況下，定義相應欄位是long long型別，通過longLongValue獲取到值，就不存在溢位的情況。

   如果這偏文章能給你帶來啟發請關注我其他的文章，或者搜尋微訊號：785798889關注我，謝謝~