在智能手机已经标配64位应用三年后，智能手表终于也开始全面拥抱64位应用。近日有消息显示，谷歌已将64位应用普及计划扩展至Wear OS智能手表操作系统，要求所有开发者从今年9月起必须提供64位版本应用。
按照谷歌方面的说法，从9月开始，开发者在Google Play Store提交Wear OS应用时不再允许仅上架32位版本，必须额外提供64位版本。当然，为了照顾老设备，Wear OS对于32位应用的支持政策暂时不变，这也就意味着搭载骁龙Wear 4100之前老平台的设备将不受影响。
那么为何直到2026年，谷歌才强制要求Wear OS应用必须有64位版本？事实上，早在2015年秋季，ARM就推出了面向智能手表的64位应用处理器设计方案Cortex-A35。然而Android智能手表的操作系统在过去十年并非一帆风顺，光是名字就改了三个。
最初的Android Wear诞生于2014年，彼时谷歌将其定位为“手机通知延伸”，而非独立的腕上操作系统。直到2017年的Android Wear 2.0，它才支持独立应用和应用抽屉。到了2018年春季，Android Wear更名为Wear OS by Google，才淡化“Android”色彩，更强调 “可穿戴” 定位。
由于淡化了Android，Wear OS by Google时代使用的Android底层就长期处于严重滞后的状态。比如在2020年年底，谷歌发布的“Wear OS秋季更新”，底层系统版本居然还是刚刚更名时的Android 9。过于强调可穿戴属性而忽视了智能化，也直接导致Android智能手表被Apple Watch打得溃不成军。
痛定思痛后，谷歌在2023年引入了三星Tizen作为外援，双方将Android与Tizen“合二为一”，带来了全新的Wear OS。可是整合两个不同的操作系统需要时间，如果立刻上马64位应用，新的Wear OS恐怕难以受到开发者的青睐。
如果说第三方开发者在苹果的生态里是“打工人”，那么他们在Android生态则是“合伙人”。Android的开放性使得谷歌与开发者之间的关系更接近传统的开发者社区，双方是盟友、是合作者。这种差异所导致的结果，就是苹果方面一旦调整App Store的审核指南，开发者就得跟着指挥棒跳舞，而谷歌想对Android应用的开发做出改变，就需要得到社区的支持。
在三年时间过去后，Wear OS也积累了一批忠实的开发者，这时候推广64位应用受到的抵触自然就会小很多。当然，另一个关键因素是Android智能手表在过去两年的内存规格，终于能支撑64位应用的长期运行了。
众所周知，基于冯·诺依曼架构的计算机设备是二进制的，也就是用0和1（实际是高电位和低电位）来表示信息。在工作频率相同的情况下，显然64位处理器的处理数据速度更快，这也是理论上64位更强的依据。
除了在数据处理性能上的差异，32位与64位最大的区别就在于所支持的内存上。32位系统的最大寻址空间是2^32（约4GB），64位系统的最大寻址空间则达到了2^64（16EB），这就导致64位应用可以使用动态内存分配将大于4GB的应用放到内存中处理，而32位应用就要用到类似“分块读入”的复杂方式来实现。
64位系统能够支持更大的虚拟地址空间就意味着它可以寻址更多的内存，但这也代表应用在64位模式下运行时，会比在32位模式消耗更多的内存。如果应用所需的内存不超过4GB，那么64位版本不仅无法提升性能，反而可能因内存占用增加和指令开销变大，而导致运行效率降低。
在2023年左右，Android智能手表往往还用着1GB LPDDR4内存，此时推广64位应用不是造福用户，而是给开发者和用户一起添堵。到了2026年，定位中端以上的Android智能手表内存配置起步就是2GB，所以当内存不再是瓶颈时，64位应用就会带来“免费”多出来的性能。
【本文图片来自网络】
