8月不支持64位，App将无法上架Google Play！需要怎么做？

一. 序

事情是这样的，前几天收到 Google Play 的通知邮件，这才想起来有几款在 Google Play 上架的 App，还没有支持 64 位 CPU 架构。

早在今年一月份，Google 就发布通知，在今年 8 月 1 日开始，上架的 App，除了提供 32 位的版本之外，还需要提供 64 位的版本。

这眼看着离强制升级窗口，只剩下最后两个月的时间，很多第三放来源的 so 支持库，如果没有提供 64 位的版本，还需要同步催促合作方更新。

那今天就来聊聊 Android APK 升级 64 位 CPU 架构的细节，看看你的应用是否需要支持 64 位 CPU 架构，如果要支持，需要做什么?

二. Android CPU 架构细节

2.1 这是强制规范

早在 2015 年 Google 发布 Android 5.0 版本时，就加入了 64 位处理器的支持，当时就提出了以 19 年 8 月为最后的更新支持期限，并在今年又重申了这个强制要求。

只要你的 App 存在国际版，需要上架 Google Play，这个规定都必须准守。

2.2 那些 APK 需要支持 64 位?

那假如你有一个国际化的 App 需要维护，在今年 8 月 1 日之后，更新 Google Play 时，就必须提供 64 位的版本。

那这里说的 64 位版本支持，到底是什么?

如果你的应用，完全是使用 Java 或者 Kotlin 编写代码，不包含任何原生(Native)的支持，那么就表示这个应用已经支持 64 位。

但是应用内使用了任何原生(Native)的支持(so 库)，就需要针对这些 so 文件，针对不同的 CPU 架构提供不同的版本的 so 支持。

需要注意的是，有些时候，在我们自身的代码中，确实没有用到原生的支持，但是在 App 中使用的一些第三方库中却包含了。

此时最稳妥的方式，就是针对最终打包生成的 APK 文件进行分析，来判断是否需要提供 64 位架构的支持。

那 CPU 架构是什么?什么又是 ABIs?

在 Android 中，虽然 ARM 的 CPU 架构是主流，但是目前至少支持几类 CPU 架构，ARM 下的 ARMv5/ARMv7/ARMv8，x86 下的 x86/x86_64，以及很不常见的 MIPS 类架构。这里的每一种 CPU 类型对应了一种 ABI(Application Binary Interface)，例如 armeabi-v7a 中的 "armeabi" 指的就是 ARM 这种类型的 ABI，后面的 “v7a” 指的是 ARMv7。

通常我们可以简单的理解：

这三个概念是相通的，通常在技术讨论中，说的是一个东西。

2.3 为什么是强制的?

谷歌之所以会有强制更新的要求，很大一方面原因是因为作为开发者，更新补全 ABIs 的动力并不足。

主要原因来自以下几个方面：

1. APK 体积增大

针对不同 CPU 架构提供对应的 so 库，当然是效率最高的做法。但是这种做法，最直接的影响，就是 APK 文件的增大，有些时候补全这些 so 支持，会导致整个 APK 体积有几 MB 到几十 MB 的增幅。

APK 体积优化，很多公司都将其算做是一个 KPI 指标，加入一个新特性，导致 APK 体积的增大，在很多时候都是不允许的，为此换技术方案都是常有的事。

从增长的角度来看，越小的 APK，用户下载的意愿就更大，转化率就越高。

但是随着现在流量越来越便宜，近期 iOS 已经将 蜂窝数据下载限制从 150MB 放宽至 200MB，针对安装包的体积优化标准，也可以适当的放宽了。

2. 本身有一定的兼容性

应用市场中，很多 APP 其实都只有 armeabi 或者 armeabi-v7a 的支持，而市面上的设备，支持的并不是只有这两种 CPU 架构。

但是这并没有影响在这些设备上运行这些 App，这就是 CPU 架构的兼容性。

不同架构，并不意味着之间一定是不兼容的，在不同版本下，其实提供了两种 ABI 支持，分别是

• 主要 ABI：与系统本身使用的原生代码一样，最优方案。
• 辅助 ABI：支持的另一个 ABI 方案，兼容方案。

这种兼容策略就不在这里展开说了，最简单的就是 64 位的 arm64-v8a 在支持本身的 CPU 架构之外，还兼容支持 armeabi-v7a、armeabi;x86_64 同时也兼容支持 X86 和 armeabi。

你看，虽然添加 64 位的支持，可以有效的使用硬件的优势，提升性能，但大部分时候，采用兼容方案，是一种更简单的方式。

3. 没有对应架构的 so 文件

这个原因就比较尴尬了，我们 App 中使用到的原生代码，其实有两种。

一种是我们自己编写的，源码在手，想提供对应的支持，修改配置重新编译一下就解决了。

另一种来自第三方提供的，这种时候我们没有源码，无法做到重新编译，只能和第三方沟通，看能不能提供一个对应 CPU 架构的 so 库。这种情况就非常的不可控了。

例如比较常见的一个 WebView 的替换方案，腾讯 X5 内核，本身就不提供 X86 的库。

官方给的建议是使用 armeabi 或者 armeabi-v7a。

在前文有提到，ABIs 本身是有一些兼容规则的，但是这种兼容规则，是有条件的。

举个例子：64 位的 arm64-v8a 是可以向下兼容的，但是这有个前提，那就是如果你的项目中，有 armeabi-v7a 和 arm64-v8a 两个目录，就需要保证这两个目录下支持的 so 库文件保持一致。

在左边的情况下，如果 arm64-v8a 的手机用到 b.so 时，就会去 arm64-v8a 目录下找，当然是找不到 b.so 文件的，就会直接抛异常，而不会再去 armeabi-v7a 目录下继续寻找。

如果需要提供多套 ABIs 的支持，就需要保证所有 ABI 目录下，对应的 so 文件保持一致。

而在一些特殊的情况下，我们无法提供对应平台的 so 库，例如腾讯 X5 内核这种情况，就需要做个取舍了。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!