这一次谷歌很强硬，从现在起你的App再不支持，将拒绝上架！

点击“开发者技术前线”&＃xff0c;选择“星标?”

13&＃xff1a;21 在看|星标|留言,  真爱

作者: 承香墨影 | 编辑&＃xff1a;可可

一. 序

为什么不让上架&＃xff0c;事情是这样的&＃xff0c;前几天收到 Google Play 的通知邮件&＃xff0c;这才想起来有几款在 Google Play 上架的 App&＃xff0c;还没有支持 64 位 CPU 架构。

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

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

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

二. Android CPU 架构细节

2.1 这是强制规范

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

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

2.2 那些 APK 需要支持 64 位&＃xff1f;

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

那这里说的 64 位版本支持&＃xff0c;到底是什么&＃xff1f;

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

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

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

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

那 CPU 架构是什么&＃xff1f;什么又是 ABIs&＃xff1f;

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

通常我们可以简单的理解&＃xff1a;

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

2.3 为什么是强制的&＃xff1f;

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

主要原因来自以下几个方面&＃xff1a;

1. APK 体积增大

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

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

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

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

2. 本身有一定的兼容性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在没有 Google Play 的强制策略下&＃xff0c;同时又因为各方考虑&＃xff0c;大多数时候我们可能会舍弃其他 ABIs 的支持。但是现在既然强制执行了&＃xff0c;腾讯 X5 内核就可能升级以提供 64 位的 so 库&＃xff0c;毕竟一边是无法上架&＃xff0c;另外一遍是一个 WebView 的内核&＃xff0c;谁都知道怎么取舍。

三、支持 64 位架构

3.1 是否包含 64 位库&＃xff1f;

介绍了 Android 下 CPU 架构的一些细节&＃xff0c;接下来就要开始正题了&＃xff0c;如何升级并支持 64 位架构。

从前文中应该了解到&＃xff0c;支持对应的 ABIs&＃xff0c;反映在项目中&＃xff0c;就是存在对应 ABIs 架构的目录&＃xff0c;并且目录中有完备的 so 库支持。

Google 并不要求我们支持所有的 64 位架构&＃xff0c;但是对于已经支持的每种原生 32 位架构&＃xff0c;就必须包含对应的 64 位架构。

例如&＃xff1a;

这就要求我们有对应的目录&＃xff0c;并且目录中包含对应的 so 文件。APK 中提供了完备的 ABIs 支持&＃xff0c;运行的之后&＃xff0c;会选取对应的最优支持进行加载和使用。

需要注意的是&＃xff0c;有时候我们将 32 位的 so 复制到 64 位中&＃xff0c;运行不会出现异常&＃xff0c;但是这依然存在隐患。最好的办法是根据不同的架构&＃xff0c;编译对应的 so 文件&＃xff0c;原则上&＃xff0c;我们的目标是确保应用可以在仅支持 64  位架构的环境中正常运行。

3.2 判断是否支持 64 位架构

前面也提到&＃xff0c;我们的项目中&＃xff0c;可能会引入一些第三方库&＃xff0c;导致在不明确的情况下&＃xff0c;引入了一些预期之外的 ABIs 库。

通常我们的做法是在 Gradle 中增加 abiFilters 过滤&＃xff0c;来确保不会在打包输出的 APK 中存在预期之外的 ABIs 目录和 so 库。

ndk {    //设置支持的SO库架构    abiFilters &＃39;armeabi-v7a&＃39; }
    abiFilters &＃39;armeabi-v7a&＃39; 
}


那么我们拿最终打包输出的 APK 文件去分析&＃xff0c;是最稳妥的办法。

分析的方法有两种&＃xff1a;

1. AS 的 APK 分析器

在 Android Studio 中&＃xff0c;从菜单依次选择  Build → Analyze APK…

选择需要分析的 APK 文件&＃xff0c;查看其 lib 目录&＃xff0c;是否存在预期的 ABIs 目录以及完备的 so 文件。

2. 使用 zipinfo 命令进行分析

得到待分析的 APK 文件&＃xff0c;就可以通过 zipinfo &＃43; grep 命令&＃xff0c;输出其内包含的 so 文件。

> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$    lib/armeabi-v7a/libmain.so    lib/armeabi-v7a/libmono.so    lib/armeabi-v7a/libunity.so    lib/arm64-v8a/libmain.so    lib/arm64-v8a/libmono.so    lib/arm64-v8a/libunity.so zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
    lib/armeabi-v7a/libmain.so
    lib/armeabi-v7a/libmono.so
    lib/armeabi-v7a/libunity.so
    lib/arm64-v8a/libmain.so
    lib/arm64-v8a/libmono.so
    lib/arm64-v8a/libunity.so


依然是去看对应目录和 so 文件是否完备。

3.3 在 64 位设备上测试应用

支持 64 位架构是为了让我们利用 CPU 的特性&＃xff0c;以提升性能&＃xff0c;但是稳定依然是我们首先要保证的&＃xff0c;所以在升级之后&＃xff0c;就需要进行测试。

要测试 App&＃xff0c;最简单的方式是使用 adb 命令安装该应用&＃xff0c;可以配合 --abi 参数&＃xff0c;用以指示要将那些 so 库&＃xff0c;安装到设备上&＃xff0c;这样我们在这个设备上安装的 App&＃xff0c;就会仅包含我们制定的库。

# 成功安装 APK :> adb install --abi armeabi-v7a YOUR_APK_FILE.apkSuccess# 如果 APK 中不包含 64 位 so 文件:> adb install --abi arm64-v8a YOUR_APK_FILE.apkadb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res&＃61;-113]# 如果你的设备&＃xff08;手机&＃xff09;不支持 64 位架构> adb install --abi arm64-v8a YOUR_APK_FILE.apkABI arm64-v8a not supported on this device 成功安装 APK :
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# 如果 APK 中不包含 64 位 so 文件:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res&＃61;-113]

# 如果你的设备&＃xff08;手机&＃xff09;不支持 64 位架构
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device


去年上市的手机&＃xff0c;大部分都是 64 位架构的&＃xff0c;找一款来测试即可。

3.4 分包处理

如果我们的应用只需要在国内分发&＃xff0c;当前的策略对我们并不影响&＃xff0c;保持原样就好了。但是如果存在国际版&＃xff0c;需要上架 Google Play 就一定要重视此次升级。

在 Google Play 上传 APK&＃xff0c;是可以根据 CPU 架构上传不同的 APK 的&＃xff0c;也就是我们可以针对 32 位上传一个 APK&＃xff0c;再上传一个 64 位的 APK。

此时就需要用到 Gradle 的打包技巧了&＃xff0c;分别输出几个仅包含对应平台的 APK&＃xff0c;以此完成 Google Play 的要求&＃xff0c;分别上传 32 位的支持 APK 和 64 位的支持 APK&＃xff0c;这样能够 APK 文件不至于增大很多。

android {    ...     splits {        abi {            enable true            reset()            include &＃39;x86&＃39;, &＃39;x86_64&＃39;, &＃39;armeabi-v7a&＃39;, &＃39;arm64-v8a&＃39; //select ABIs to build APKs for            universalApk true //generate an additional APK that contains all the ABIs        }    }    // map for the version code    project.ext.versionCodes &＃61; [&＃39;armeabi&＃39;: 1, &＃39;armeabi-v7a&＃39;: 2, &＃39;arm64-v8a&＃39;: 3, &＃39;mips&＃39;: 5, &＃39;mips64&＃39;: 6, &＃39;x86&＃39;: 8, &＃39;x86_64&＃39;: 9]    android.applicationVariants.all { variant ->        // assign different version code for each output        variant.outputs.each { output ->            output.versionCodeOverride &＃61;                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 &＃43; android.defaultConfig.versionCode        }    } }
    splits {
        abi {
            enable true
            reset()
            include &＃39;x86&＃39;, &＃39;x86_64&＃39;, &＃39;armeabi-v7a&＃39;, &＃39;arm64-v8a&＃39; //select ABIs to build APKs for
            universalApk true //generate an additional APK that contains all the ABIs
        }
    }
    // map for the version code
    project.ext.versionCodes &＃61; [&＃39;armeabi&＃39;: 1, &＃39;armeabi-v7a&＃39;: 2, &＃39;arm64-v8a&＃39;: 3, &＃39;mips&＃39;: 5, &＃39;mips64&＃39;: 6, &＃39;x86&＃39;: 8, &＃39;x86_64&＃39;: 9]

    android.applicationVariants.all { variant ->
        // assign different version code for each output
        variant.outputs.each { output ->
            output.versionCodeOverride &＃61;
                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 &＃43; android.defaultConfig.versionCode
        }
    }
 }


这里利用 Gradle 的 splite 配置&＃xff0c;有兴趣可以直接查阅文档&＃xff0c;就不展开讲了。

四. 小结

在本文中&＃xff0c;我们借此次 Google Play 的强制支持 64 位架构的事情&＃xff0c;讲解了 Android 下 so 库的一些兼容问题。

如果你在 Google Play 上有应用需要更新&＃xff0c;别忘了提前准备需要的 so 库&＃xff0c;大多数原生支持的第三方库&＃xff0c;在此之前其实都已经提供了对应的 64 位架构。我们只需要在最终日期之前&＃xff0c;仔细的进行增加 so 文件&＃xff0c;以达到适配的效果。

更新完成之后&＃xff0c;别忘了测试&＃xff0c;本文就到这里&＃xff0c;你有什么更新的见解&＃xff0c;欢迎在留言区讨论。

本文对你有帮助吗&＃xff1f;留言、转发、点好看是最大的支持&＃xff0c;谢谢&＃xff01;星标好文方便第一时间阅读

---END---

选择”开发者技术前线 “星标?&＃xff0c;内容一触即达。点击原文更多惊喜&＃xff01;

开发者技术前线 汇集技术前线快讯和关注行业趋势&＃xff0c;大厂干货&＃xff0c;是开发者经历和成长的优秀指南。

历史推荐

为了给小女友挑合适罩杯的内衣&＃xff0c;我用  Python 爬了淘宝内衣店的数据&＃xff01;

重磅&＃xff01;华为8月将正式发布鸿蒙&＃xff0c;鸿蒙要比安卓原生快60%

Google 出品 Java 编码规范&＃xff0c;强烈推荐&＃xff01;

点个在看&＃xff0c;解锁更多惊喜&＃xff01;