64 位移動處理器在 2013 年首次亮相，而蘋果 iOS 系統則是首個支援 64 位元計算的移動作業系統。有意思的是，從最近的消息瞭解，蘋果將有可能在 iOS 11 正式放棄對 32 位元應用程式的支援，正式完成對 64 位元生態系統的完全過渡。其實這是 iOS 10.3 測試版一個錯誤資訊無意間爆的料，當用戶嘗試運行 32 位元應用程式，系統竟然告訴使用者無法在未來版本中運行，開發者需改進適配，正是這點讓人浮想聯翩。
在 iOS 平臺上，蘋果已經不止一次提供類似的暗示了，並非常希望開發者僅提供 64 位元應用程式。例如說，去年年底的時候，蘋果從 App Store 移除了一定數量應用程式，理由是不相容，並向開發者發送電子郵件，提醒他們應用程式開發必須以 64 位為基礎。
通常來說，我們不太會在意系統或手機是 32 位還是 64 位元，畢竟新設備總是能夠同時相容 32 位和 64 位元應用程式。但是，考慮到蘋果總是能對穀歌移動生態系統產生一定的影響，就有必要來討論一下，為何蘋果要做出這樣的舉動，而 Android 是否應該效仿。
32 位和 64 位
首先要簡單的瞭解一下 32 位和 64 位的背景。32 位和 64 位一般是指 CPU 的通用寄存器位寬，相對於 32 位而言， 64 位的 CPU 位寬增加一倍，使其能夠處理更多更精確的資料，因此有一定加快資料處理的作用，特別是負載的情況下。再通俗來講，32 位和 64 位就是四車道和八車道的區別，在擁堵的晚高峰，八車道速度顯然更快。
當然了，64 位可定址範圍大大擴展，32 位元系統最大支援記憶體為 4G。另外，32 位元系統和 64 位元系統需要安裝支援相應軟體模式下的作業系統和驅動軟體，也就是 32 位只能安裝 32 位，64 位安裝 64 位元的軟體，但可相容 32 位運算。
回到 ARM 處理器的話題上。ARM 從 32 位 ARMv7-A 到 32 位/ 64 位 ARMv8-A 的轉變過程中，引入了大量的新指令以便增強功能，也就是 AArch64 指令集。但為了保證 ARMv8 能夠向後相容，AMR 在架構設計上仍保留了現有的 AArch32 和 Thumb-32 指令集。雖然這就意味著 CPU 核心管線部分需要進行更多設計，佔用更多極其有限的晶片空間，但確保了這些傳統指令也能夠與新硬體一起工作。
需要注意的是，單個應用程式使用過長中，完全不可能同時使用 ARMv7 和 ARMv8 兩種執行狀態，因為 AArch64 與 AArch32 和 Thumb-32 指令集之間沒有任何交交互操作。因此，直接以 AArch64 指令集和 ARMv8 處理器為基礎編寫的應用程式，無法在 ARMv7 Cortex-A 系列處理器上運行。不過，以 ARMv7 Cortex-A 處理器為基礎編寫的應用程式，仍可以在 ARMv8 處理器上運行，畢竟可通過保留的 AArch32 和 Thumb-32 執行狀態運行。
其實說白了，如果蘋果真那麼做的話，像 iPhone 5 這款以 ARMv7 處理器為基礎的機子，將無法升級到 iOS 11 作業系統。
蘋果為何執意轉向 64 位
蘋果放棄對 32 位元應用程式的支援表明，未來將完全擁抱 AArch64執行狀態，其硬體處理器和軟體 iOS 系統，還有應用程式的設計，所有都將只適用於 AArch64 指令集功能。好處自然不少，包括更大的定址範圍支援更大的記憶體，簡化組合語言程式，雙精度浮點及更先進的 SIMD 運算，以及高達 3 至 10 倍的加速硬體加密性能等。
不過，開發者和開發商將無法再使用 AArch32 和 Thumb-32 指令集，因為必須更新應用程式。當然了，除了迫使開發人員利用全新 64 位架構的最新特性之外，這也十分有利於蘋果更出色的完成下一代 CPU 的設計工作。蘋果有出色的晶片設計團隊，而且一直在規劃放棄對舊架構的支持，完全可以借此盡可能多地釋放晶片空間，降低製造成本，或者將釋放的空間加以利用，加強 CPU、GPU 及其餘部分，或引入更加先進的一些功能。
我們不清楚蘋果如何設計下一代晶片，或許會是為 64 位進一步優化 CPU，而不一定是全部轉為 64 位元，保留部分傳統硬體所需的 32 位元指令，不會強行破壞與 ARM 簽署的授權合約。因為 ARM 通常要求基於其授權架構的 CPU 設計，務必支援全部指令集，若遵守這一規定的話，蘋果的晶片同樣需要保留對 AArch32 和 Thumb-32 的支持，如此一來才能通過 ARM 的一致性測試。
不過，ARM 自己提倡靈活性設計，例如 Cortex-A32 就是基於 32 位版本的 ARMv8架構設計，沒有十分明確哪些指令集是強制性要求，這就相當於留給蘋果更多的發揮空間。
那麼，Android 陣營應該跟風？
有利有弊，而且也並非完全不可行，若是基於上述相同的原因，只要谷歌和智慧手機晶片開發商（如高通和聯發科）聯手，軟體和硬體上共同合作也能實現。但不可否認的是，Android 生態圈比蘋果大很多，分佈有大量不同的硬體設定，若立即執行同樣的轉變相信很難迅速組織起來，甚至在此過程中可能被迫中斷。
儘管如此，理論上穀歌也可以從軟體方面做類似的事情，強制要求所有 Google Play 商店的應用程式轉移到 64 位版本。不過，這同樣需要一個長期的過渡時間，雖然今天入門級的智慧手機和平板電腦都已經裝備了 64 位 處理器，但是依然依賴于大量的 32 位元應用程式，而且真正完美相容 64 位元指令集的並不是很多，一旦放棄向後相容後果不堪設想。
講真的，Android 生態圈完全遷移到 64 位不太靠譜。例如說，許多 Android 車載娛樂系統仍基於ARMv7 處理器打造。再看智慧手錶，包括華為、索尼和 LG 的手錶，均搭載了 32 位的ARM Cortex-A7 處理器設計。另外，穀歌最近公佈的 Android Things 物聯網平臺，其開發板的晶片也並沒有相容 64 位元的應用程式。
那 Android 陣營沒辦法全面過渡到單一的 64 位計算了？並非如此，只是可以預見，未來 Android 依然提供 32 位的支持，這是最兩全其美的解決方案。