前言
随着市面上手机架构的不断升级换代，越来越多的手机已经开始使用arm64-v8a的cpu架构了，带来的好处就是手机的性能的极大的提升，但是一直使用armeabi和armeabi-v7a就享受不到arm64-v8a带来的澎湃感了，所以项目组决定适配arm64-v8a。
适配过程
- 查找项目中的so库
首先在Android studio中点击build-> Clean Project，清除掉build产生的文件，然后点击底部的Terminal打开命令行窗口，切换到项目根目录并执行命令:
find . -name '*.so'
命令行中会展示出项目中导入的第三方so库，根据打印出的路径分别找到对应的so库的位置，补齐armeabi-v7a同级目录的arm64-v8a对应的so库（需要从第三方获取） - 查找项目中的aar
find . -name '*.aar'
找到引入的第三方aar包，在Android studio中双击打开aar包，如果aar包中包含jni目录一定要检查jni目录中是否同时存在armeabi-v7a和arm64-v8a，如果不全，需要从第三方获取 - 修改打包配置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.
}
}
- 谷歌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"))
}
如果项目中集成了热更新相关功能或存在版本升级的判断逻辑，需要注意上面的代码对于版本号的影响，在做版本比对前要进行版本号还原操作。
- 上面的配置完成后可以进行打包测试，最终打出来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库，完事！
