安卓|从谷歌到手机厂商都下决心了,要清除32位应用这匹“害群之马”( 二 )





由于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位应用才更契合这一特征 。

相关经验推荐