Android应用程序适配armeabi-v7a和arm64-v8a的CPU架构

前言

随着市面上手机架构的不断升级换代，越来越多的手机已经开始使用arm64-v8a的cpu架构了，带来的好处就是手机的性能的极大的提升，但是一直使用armeabi和armeabi-v7a就享受不到arm64-v8a带来的澎湃感了，所以项目组决定适配arm64-v8a。

适配过程

1. 查找项目中的so库
   首先在Android studio中点击build-> Clean Project，清除掉build产生的文件，然后点击底部的Terminal打开命令行窗口，切换到项目根目录并执行命令:
   find . -name '*.so'
   命令行中会展示出项目中导入的第三方so库，根据打印出的路径分别找到对应的so库的位置，补齐armeabi-v7a同级目录的arm64-v8a对应的so库（需要从第三方获取）
2. 查找项目中的aar
   find . -name '*.aar'
   找到引入的第三方aar包，在Android studio中双击打开aar包，如果aar包中包含jni目录一定要检查jni目录中是否同时存在armeabi-v7a和arm64-v8a，如果不全，需要从第三方获取
3. 修改打包配置app/build.gradle，删除ndk方式的apiFilters，这种方式打出来的包会包含armeabi-v7a和arm64-v8a两个so库，size比较大，弃用！
   // ndk { abiFilters 'armeabi-v7a','arm64-v8a' }
   splits会打出两个apk，一个只有armeabi-v7a的apk和一个只有arm64-v8a的apk，应用市场会针对不同的架构自动展示适用当前手机架构的apk，增加splits方式的abi配置：

android {
    defaultConfig {
    ...
    }

    def isReleaseBuild = false
    gradle.startParameter.taskNames.find {
        // Enable split for release builds in different build flavors
        // (assemblePaidRelease, assembleFreeRelease, etc.).
        isReleaseBuild = it ==~ /:app:assemble.*Release/
        return isReleaseBuild
    }

    splits { // Configures multiple APKs based on ABI.
        abi {
            enable isReleaseBuild  // Enables building multiple APKs per ABI.
            reset() // Resets the list of ABIs that Gradle should create APKs for to none.
            include 'armeabi-v7a', 'arm64-v8a'
            universalApk false // Specifies that we do not want to also generate a universal APK that includes all ABIs.
        }
    }

4. 谷歌Play 商店不允许同一个应用的多个 APK 全都具有相同的版本信息，因此在上传到 Play 商店之前，您需要确保每个 APK 都有自己唯一的 versionCode，需要增加如下配置：

android {
    ...

    // https://developer.android.com/studio/build/configure-apk-splits#kts
    // map for the version code
    def abiCodes = ['armeabi-v7a': 1, 'arm64-v8a': 2]
    applicationVariants.all { variant ->
        if (variant.buildType.name != "debug") {
            variant.getPackageApplicationProvider().get().outputDirectory = new File(project.rootDir.absolutePath + "/apk")
        }
        
        variant.outputs.forEach {
            it.outputFileName = it.getFilter(it.ABI) + "/" + variant.flavorName + variant.buildType.name + "_" +
                    variant.versionName + "_" +
                    releaseTime() +
                    ".apk"

            // Google Play 商店不允许同一个应用的多个 APK 全都具有相同的版本信息，因此在上传到 Play 商店之前，您需要确保每个 APK 都有自己唯一的 versionCode
            // https://developer.android.com/studio/build/configure-apk-splits#kts
            // map for the version code
            def baseAbiVersionCode = abiCodes.get(it.getFilter(it.ABI))
            if (baseAbiVersionCode != null) {
                // TODO 版本升级逻辑中versionCode要切割个位数为arch号，剩余部分为实际的versionCode
                it.versionCodeOverride = baseAbiVersionCode * 10 + variant.versionCode
            }
        }
    }
}
static def releaseTime() {
    return new Date().format("yyyy-MM-dd_HH:mm", TimeZone.getTimeZone("Asia/Chongqing"))
}

如果项目中集成了热更新相关功能或存在版本升级的判断逻辑，需要注意上面的代码对于版本号的影响，在做版本比对前要进行版本号还原操作。

5. 上面的配置完成后可以进行打包测试，最终打出来apk后，在Android studio中双击打开，找到对应的apk
   
   截屏2021-06-11 下午4.44.23.png
   
   比对两个apk包中包含的so数量，如果数量不同，找到对不上的so并分析从出处，补齐so，然后继续第5步操作。如果数量相同，恭喜你！适配工作完成，
   到手机上跑一下adb shell getprop ro.product.cpu.abi命令可以查看手机架构，我找遍公司里的测试机，也没找到32位架构的，看来这次升级还是很有必要的。自测没问题就可以提交测试了。

分享一下个人在适配过程中遇到的坑，有同事之前在做armeabi升级到armeabi-v7a的时候，在打包完成后发现armeabi中的so数量和armeabi-v7a中的数量对不上，然后找到对不上的so直接从apk中复制到了项目中的armeabi-v7a包中，时间一长就忘了这回事，再加上项目仓库发生了几次改变，之前的提交记录也找不全了，导致在我的这次适配中不知道这几个so库是哪里来的，也就不知道该从哪里搞到对应的arm64-v8a的so库，也不敢随意删除。commit记录找到了提交人，提交人也想不起来了，于是在豌豆荚上找到了几个很旧的apk包，解压发现里面存在这几个库，但是同时期gatlab tag下面的代码里并没有这几个so库，进一步猜测是同事手动从apk中加进来的。在这个tag下经过一番查找最终确定so库是远程依赖在build的时候从网络下载到apk包中的，而项目最新代码中已经不再依赖这个三方库了，问题定位完成，直接删除这几个so库，完事！