[移动开发]Gradle配置支持小米、OPPO、VIVO等应用商店升级64位架构

一、原因

最近收到小米等应用商店升级64位架构的通知，大致内容如下：
为更好地提升APP性能体验，降低APP功耗影响，小米应用商店与OPPO应用商店、vivo应用商店共同推进国内安卓生态对64位架构的升级支持。行业适配节奏如下:

• 2021年12月底：现有和新发布的应用/游戏，需上传包含64位包体的APK包（支持双包在架，和64位兼容32位的两个形式，不再接收仅支持32位的APK包）
• 2022年8月底：硬件支持64位的系统，将仅接收含64位版本的APK包
• 2023年底：硬件将仅支持64位APK，32位应用无法在终端上运行

收到通知后查看了自己的应用后发现仅支持了32位架构（armabi，为了减少Apk包体大小）。既然各大应用商店对此有强制要求了，所以我们要针对64位架构出包了。

###二、两种方案
从应用商店看已经支持上传仅包含64位架构的APK包，所以要考虑把支持32位和64位分开打包，这样既能保证APK大小，又能满足需求。
经过研究发现有以下两种实现方式。
#####方案一
在android代码块下增加splits代码块，然后再通过添加abi代码块并配置要支持的ABI列表。
先看个例子：

andoird{
    ...
    splits{
        // 按ABI配置多个APK.
        abi {
            enable true
            reset()
            include "armeabi-v7a", "arm64-v8a"
            universalApk false
        }
    }
}

现在来解释下相关配置属性的含义。
在Gradle DSL中按ABI配置多个 APK，有如下几个属性：

• enable，是否开启根据配置的ABI进行打包，默认false，即不开启;
• exclude，指定 Gradle 不应针对哪些 ABI 生成单独的 APK，以逗号分隔列表的形式配置，不需要与reset()、include同时配置；
• reset()，清空默认的 ABI 列表，只与 include 元素结合使用，以指定您想要添加的 ABI;
• include，打包要支持ABI列表，以逗号分隔列表的形式指定 Gradle 应针对哪些 ABI 生成 APK。只与 reset() 结合使用，以指定确切的 ABI 列表；
• universalApk，是否需要打一个包含include配置的所有ABI的通用包，默认为false，若设置为true，则会除了按ABI生成的APK之外，Gradle还会生成一个通用APK

关于reset()的重要细节补充
在Android Plugin for Gradle 3.1.0及以上版本不再支持的ABI有：mips、mips64 和 armeabi，因为在NDK R17版本及以上版本不再支持这些ABI。
高版本Gradle插件默认支持的ABI为：armeabi-v7a、arm64-v8a、x86、x86_64。
reset()清除的ABI列表就是这几个，所以在未使用reset()时，默认包含了这几种架构。

下面以支持：armeabi-v7a、 arm64-v8a为实例的配置方式
采用exclude方式

andoird{
    ...
    splits{
        // 按ABI配置多个APK.
        abi {
            enable true
            //根据默认支持的abi，排除了下面两项，就剩下armeabi-v7a、arm64-v8a
            exclude "x86", "x86_64"
            universalApk false
        }
    }
}

采用reset()和include组合方式

andoird{
    ...
    splits{
        // 按ABI配置多个APK.
        abi {
            enable true
            reset()
            include "armeabi-v7a", "arm64-v8a"
            universalApk false
        }
    }
}

采用Build -> Generate signed Bundle/APK或者运行assembleRelease打包，都可以做到执行一次打包操作自动生成多个Apk包。

到这里方案一就讲完了，看起来是不是很简单。那么我们继续。

#####方案二
提到分包熟悉Android开发的应该会很快想到productFlavors，没错，第二种方案就是采用productFlavors实现的。
通过productFlavors代码块可实现产品的多维度变种，比如：vip和非vip包、版本号不相同，渠道包等

在官方文档中是这样描述的：“在某些情况下，您可能要将多个产品变种的配置组合在一起。例如，您可能要为基于 API 级别的“full”和“demo”产品变种创建不同的配置。为此，您可以使用 Android Plugin for Gradle 创建多组产品变种作为变种维度。在构建应用时，Gradle 会将您定义的每个变种维度中的产品变种配置以及 build 类型配置组合在一起，以创建最终的 build 变体。Gradle 不会将属于同一变种维度的产品变种组合在一起。”

下面仍以支持armeabi-v7a和arm64-v8a为实例，直接先看配置实例：

android{
        ...
        flavorDimensions "teacher"
        productFlavors{
            armabi_v7a{
                ndk {
                    abiFilters  "armeabi-v7a"
                }
                dimension "teacher"
            }
            arm64_v8a{
                ndk {
                    abiFilters "arm64-v8a"
                }
                dimension "teacher"
            }
        }
}

配置相关属性解释

• flavorDimensions，定义产品的维度，可以定义多个维度，用逗号分隔，配置的值对应productFlavors中的dimension属性值；
• 其中armeabi_v7a和arm64_v8a名字自己可随便定义；
• ndk，配置代码块就是打包要包含的ABI;
• abiFilters，定义打包支持的arm架构，支持配置多个，用逗号分隔，如："armeabi-v7a","x86"
• dimension，产品的维度，值必须与flavorDimensions中配置的值一致，否则会出现这种错误：The flavor 'flavor_name' is not assigned to a flavor dimension

说明
通过该方式配置打包时，需要一个个的打包，如下：
Build->Generate signed Bundle/APK方式打包示意图：

或者Gradle执行Task方式：

三、两种方案对比

通过对比发现：
1.若APP仅支持一种CPU架构，则方式一更合适；
2.若APP同时要支持arm和x86架构，则方式二更合适；

###参考Android官方文档
针对 ABI 配置多个 APK
将多个产品变种与变种维度组合在一起