对于许多帮其他人安装过Windows系统的朋友来说，或许都会先问一下是要32位还是64位的。而之所以会问这样的一个问题，是因为彼时硬件发展的限制，一些市场定位相对较低的配置基本与64位无缘。但如果说Windows的32位是时代的眼泪，那么安卓的32位无疑就是谷歌的放纵了。毕竟谁能想到，到了年、在智能手机已经进入多核时代多年后，32位应用依旧还在安卓端大行其道。
为了解决这一问题，从谷歌到各应用商店几乎都在劝开发者“弃暗投明”。日前有开发者透露，已收到小米应用商店《关于关闭新应用32位单包上传入口通知》，其中显示，年4月1日新上架的应用将不再允许单独上传32位应用包，但游戏暂时不受限制。
同时来自海外开发者论坛XDA的消息显示，提交给AOSPGerrit的代码更改了一个新的警告，只要用户在64位系统中运行32位应用就会弹出警告。而警告信息则会告诉用户，应用需要由开发者更新以提高兼容性，并敦促用户检查更新或是联系开发者。
没错，即便是如今，打开几乎任何一个安卓应用商店都还可以看到32位应用的存在，甚至于部分32位应用还是大名鼎鼎的国民级APP。但作为对比，自年的iOS7到年的iOS11，苹果方面只用了4年时间就完成了应用从32位到64位的迭代，现在iOS生态中已经没有32位APP存在。
然而，事实上谷歌开启安卓64位时代的步伐仅仅只比苹果晚了一年，并且首款支持64位的SoC（高通骁龙）和系统（Android5.0）都早在年就已亮相。
就在高通骁龙与Android5.0问世时，当时业界的主流观点，还是年搭载64位旗舰主控的安卓设备开始出货，追随iOS设备切换到64位架构，年绝大多数安卓设备都换用64位架构，并在年64位应用成为安卓生态的主流。但事实证明，除了最后的64位应用普及时间外这一预言基本准确。不仅如此，从年到年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位应用上的效率差异，最关键的原因无疑是前者是一个封闭的生态，并且苹果的掌控力相对极高，第三方开发者在某种意义上可以视作是苹果的“打工人”。可反观安卓，开放的生态造就了谷歌与开发者之间的关系，更加接近传统的开发者社区，双方是盟友、是合作者，充其量也就是谷歌的号召力更强，而第三方开发者则是一盘散沙。
这种区别所导致的结果，就是苹果方面一旦更改AppStore的审核指南，开发者就得跟着指挥棒跳舞，而谷歌想对安卓应用的开发做出改变，却需要得到社区的支持。
如今，从安卓应用商店到谷歌都开始准备强制敦促开发者将应用升级到64位，其实是因为问题已经到了非解决不可的地步，32位的天生缺陷开始逐步限制了安卓平台软件生态的进步。
在年10月，作为iOS和Android设备CPU指令集架构开发者，ARM在DevSummit开发者峰会上就已宣布，自年开始的IP设计中将逐渐取消对32位的支持。一方面是从安卓8.0开始碎片化问题逐渐得以缓解，另一方面是ARM在硬件上的限制将使得32位应用影响到用户体验，所以也使得升级64位对于安卓生态来说也就变得不得不进行了。
根据小米方面的说法，在已上市的高通骁龙8Gen1与联发科天玑平台上，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位应用就只能被束之高阁了。