對于許多幫其他人安裝過Windows系統的朋友來說，或許都會先問一下是要32位還是64位的。而之是以會問這樣的一個問題，是因為彼時硬體發展的限制，一些市場定位相對較低的配置基本與64位無緣。但如果說Windows的32位是時代的眼淚，那麼安卓的32位無疑就是谷歌的放縱了。畢竟誰能想到，到了2022年、在智能手機已經進入多核時代多年後，32位應用依舊還在安卓端大行其道。
為了解決這一問題，從谷歌到各應用商店幾乎都在勸開發者“棄暗投明”。日前有開發者透露，已收到小米應用商店《關于關閉新應用32位單包上傳入口通知》，其中顯示，2022年4月1日新上架的應用将不再允許單獨上傳32位應用包，但遊戲暫時不受限制。
同時來自海外開發者論壇XDA的消息顯示，送出給AOSP Gerrit的代碼更改了一個新的警告，隻要使用者在64位系統中運作32位應用就會彈出警告。而警告資訊則會告訴使用者 ，應用需要由開發者更新以提高相容性，并敦促使用者檢查更新或是聯系開發者。
沒錯，即便是如今，打開幾乎任何一個安卓應用商店都還可以看到32位應用的存在，甚至于部分32位應用還是大名鼎鼎的國民級APP。但作為對比，自2013年的iOS 7到2017年的iOS 11，蘋果方面隻用了4年時間就完成了應用從32位到64位的疊代，現在iOS生态中已經沒有32位APP存在。
然而，事實上谷歌開啟安卓64位時代的步伐僅僅隻比蘋果晚了一年，并且首款支援64位的SoC（高通骁龍808）和系統（Android 5.0）都早在2014年就已亮相。
就在高通骁龍808與Android 5.0問世時，當時業界的主流觀點，還是2015年搭載64位旗艦主要的安卓裝置開始出貨，追随iOS裝置切換到64位架構，2016年絕大多數安卓裝置都換用64位架構，并在2017年64位應用成為安卓生态的主流。但事實證明，除了最後的64位應用普及時間外這一預言基本準确。不僅如此，從2014年到2022年8年時間過去後，安卓的64位應用依然沒有實作全面普及。
64位應用為何在安卓平台的普及速度如此之慢？要回答這個問題，需要先弄清32位與64位這兩個關鍵詞的差別。
從馮·諾依曼機到現在如今大家熟知的個人電腦，計算機裝置是用二進制邏輯、也就是0和1（實際是高電位和低電位）來表示資訊，是以32位與64位分别指的是處理器在機關時間内能一次處理的二進制數位數分别為32位和64位。在工作頻率相同的情況下，顯然64位處理器的處理資料速度更快，這也是理論上64位更強的依據。
反過來說，用64位處理器運作32位應用則類似于"大馬拉小車"。用64位處理器計算32位應用時，其實隻需要在高電位補上“0”即可，不太會讓使用者感覺到效率差異。
與此同時，安卓長期以來呈現出的碎片化狀态，無疑也是讓谷歌遲遲難以下定決心推行64位應用的原因之一。就與windows的後向相容一樣，大量的老版本和老機型此前占據了安卓生态的半壁江山，而為了這部分使用者的體驗，安卓的後向相容性也遠比iOS出色得多。
由于32位應用可以運作在64位系統上，并且代價卻微乎其微，可如果将應用全面轉型64位，結果就是那些依然在使用32位系統的使用者再将無法使用，這所代表的無疑就是使用者流失。而如果同時開發32位與64位版本，也就意味着工作量切切實實地提高了。既然32位應用在新版安卓系統中依然能夠運作，且效率也沒有太大的差別，自然也就會導緻開發者将32位應用更新到64位的意願就不會太強。
而iOS與安卓在推行64位應用上的效率差異，最關鍵的原因無疑是前者是一個封閉的生态，并且蘋果的掌控力相對極高，第三方開發者在某種意義上可以視作是蘋果的“打勞工”。可反觀安卓，開放的生态造就了谷歌與開發者之間的關系，更加接近傳統的開發者社群，雙方是盟友、是合作者，充其量也就是谷歌的号召力更強，而第三方開發者則是一盤散沙。
這種差別所導緻的結果，就是蘋果方面一旦更改App Store的稽核指南，開發者就得跟着指揮棒跳舞，而谷歌想對安卓應用的開發做出改變，卻需要得到社群的支援。
如今，從安卓應用商店到谷歌都開始準備強制敦促開發者将應用更新到64位，其實是因為問題已經到了非解決不可的地步，32位的天生缺陷開始逐漸限制了安卓平台軟體生态的進步。
在2020年10月，作為iOS和Android裝置CPU指令集架構開發者，ARM在DevSummit開發者峰會上就已宣布，自2022年開始的IP設計中将逐漸取消對32位的支援。一方面是從安卓8.0開始碎片化問題逐漸得以緩解，另一方面是ARM在硬體上的限制将使得32位應用影響到使用者體驗，是以也使得更新64位對于安卓生态來說也就變得不得不進行了。
根據小米方面的說法，在已上市的高通骁龍8 Gen 1與聯發科天玑9000平台上，32位應用僅支援在CPU大核上運作，這會導緻存在一些發熱及功耗等體驗方面的問題。
而對于ARM架構有所了解的朋友想必知道，目前主流的ARM架構晶片都采用的是big.LITTLE大小核切換技術，這是一項可以将正确的任務排程到正确CPU核心的技術，可以讓大核心負責遊戲等高負載任務、小核心負責聽歌、浏覽網頁等低負載任務。但這一技術的代價是晶片的工作模式必須統一，不能是大核使用AArch64指令集，小核使用AArch32指令集。
big.LITTLE技術的局限性，以及ARM方面對于32位應用的限制，就意味着部分本應運作在小核上的低負載應用被迫使用大核，再加上這一代旗艦SoC本身在功耗及發熱方面的表現，影響日常使用也成為了闆上釘釘的事情。大家不妨想象一下，如果單純隻是在用手機刷微網誌、聽歌，此時手機居然會開始發熱，這又有誰能受得了呢？通常消費者此時可能就會吐槽手機本身有設計缺陷了，但對于廠商來說可謂是人在家中坐、鍋從天上來。
即便抛開上述這些問題，32位應用也早就沒有了未來。除了在資料處理性能上的不同外，32位與64位最大的差異就在于所支援的記憶體上（請注意，這裡的記憶體指的是位址空間，而不是實體記憶體）。32位系統的最大尋址空間是2^32（約4GB），64位系統的最大尋址空間為2^64（16EB），這就導緻了64位應用可以使用動态記憶體配置設定将一個大于4GB的應用放到記憶體進行處理，而32位應用就需要使用類似“分塊讀入”的複雜方式來完成。
簡單來說就是，32位應用理論上最大隻支援4GB記憶體，而另外使用64位記憶體指針則會使應用“膨脹”，占用更多的緩存和記憶體，并讓消費者對于更大記憶體和大容量閃存的需求增加。要知道當下主流機型的記憶體至少已經從6GB起步、8GB是标配，12GB也并不少見，無疑也使得64位應用才更契合這一特征。
如今從谷歌到蘋果，再到各大手機廠商，早已紛紛将移動辦公、移動娛樂作為重點的情況下，無疑手機要承載的功能也就更多、應用場景也愈發豐富，是以先天有缺陷的32位應用就隻能被束之高閣了。
【本文圖檔來自網絡】