// 适配指定CPU架构
ndk {
abiFilters ‘arm64-v8a’, ‘x86_64’
}
}
}
效果如下:
可以看到,只生成了我们指定CPU架构的so文件,包的大小也减少了5.3MB
。
这时候,你可能会有一个疑问,Android 共支持7种CPU架构,那么,我们在实际项目中该适配哪些CPU架构能保证最好的兼容,同时又最大限度的减少APK的大小?
在回答这个问题之前,我们不妨看一下这些顶级巨头公司,他们是是如何适配的。
3. 目前大厂APP是如何适配不同的CPU架构的?
首先,我们下载一些大厂的APK,看一下他们的适配情况,这里我分析了微信、手机QQ、支付宝和淘宝这4个APP的适配情况:
可以看到,微信适配的是arm64-v8a
(微信应该是最近才适配到arm64-v8a
,以前是armeabi
),支付宝和手Q适配的是armwabi
,淘宝适配的是armwabi-v7a
。各个APP适配的平台不太一样,但是他们有一个共同点,那就是它们只指定了一个平台。
等等,上面这些APP只适配了一中CPU架构,比如只适配了armwabi-v7a
,那如果APP装在其他架构的手机上,如arm64-v8a
上,会蹦吗?
要弄清楚这个问题,我们得先搞清楚,ABI是如何工作的。
ABI是如何工作的呢?
官方文档解释如下:
Android 系统在运行时知道它支持哪些 ABI,因为版本特定的系统属性会指示:
- 设备的主要 ABI,与系统映像本身使用的机器代码对应。
- (可选)与系统映像也支持的其他 ABI 对应的辅助 ABI。
此机制确保系统在安装时从软件包提取最佳机器代码。
为实现最佳性能,应直接针对主要 ABI 进行编译。例如,基于 ARMv5TE 的典型设备只会定义主 ABI:armeabi。相反,基于 ARMv7 的典型设备将主 ABI 定义为 armeabi-v7a,并将辅助 ABI 定义为 armeabi,因为它可以运行为每个 ABI 生成的应用原生二进制文件。
64 位设备也支持其 32 位变体。以 arm64-v8a 设备为例,该设备也可以运行 armeabi 和 armeabi-v7a 代码。但请注意,如果应用以 arm64-v8a 为目标,而非依赖于运行 armeabi-v7a 版应用的设备,则应用在 64 位设备上的性能要好得多。
许多基于 x86 的设备也可运行 armeabi-v7a 和 armeabi NDK 二进制文件。对于这些设备,主 ABI 将是 x86,辅助 ABI 是 armeabi-v7a。
上面这一段是不是有点看蒙了,这里我来简单解释以下。总的来说,就是一个Android设备可以支持多种ABI,设备主ABI和辅助ABI,以arm64-v8a
为主ABI的设备,辅助ABI为