在智能手机已经标配 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 位应用就会带来 " 免费 " 多出来的性能。

【本文图片来自网络】