Android架构 armeabi、armeabi-v7a、arm64-v8a、x86详解

大家好，欢迎来到IT知识分享网。

最近在用flutter打包的时候，遇到了包打不出来的情况，后面查了半天原因，发现是没有配置arm导致的，配了之后就打出来了，乘着这个契机，重头来学习了一下abi

开始之前

开始之前先需要知道lib、libs等知识

一. lib和libs

二. .so库

三. .so库该如何存放

四. libs下armeabi等的作用是什么

架构介绍

adb shell getprop ro.product.cpu.abi 

ABI是如何工作的

2020.06更新， 看到一篇很好的文章搬过来了，感谢原作者(https://juejin.im/post/5eae6f86e51d454ddb0b3dc6)

官方文档解释如下：
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为armeabi-v7a和armeabi，以armeabi-v7a为主ABI的设备，辅助ABI为armeabi。
另外，x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现对 arm .so 的兼容，也就是说有适配armeabi平台的APP是可以跑在x86手机上的。

ABI具体适配流程

对于一个cpu是arm64-v8a架构的手机，它运行app时，进入jnilibs去读取库文件时，先看有没有arm64-v8a文件夹，如果没有该文件夹，去找armeabi-v7a文件夹，如果没有，再去找armeabi文件夹，如果连这个文件夹也没有，就抛出异常；
如果有arm64-v8a文件夹，那么就去找特定名称的.so文件，注意：如果没有找到想要的.so文件，不会再往下（armeabi-v7a文件夹）找了，而是直接抛出异常。

我们项目中该如何适配呢

• 只适配armeabi的APP可以跑在armeabi,x86,x86_64,armeabi-v7a,arm64-v8上
• 只适配armeabi-v7a可以运行在armeabi-v7a和arm64-v8a
• 只适配arm64-v8a 可以运行在arm64-v8a上

方案二：只适配 armeabi-v7a

同理方案一，只是又筛掉了一部分老旧设备,在性能和兼容二者中比较平衡

方案三: 只适配 arm64-v8

这三种方案都是可以的，现在的大厂APP适配中，这三种都有，大部分是前2种方案。具体选哪一种就看自己的考量了，以性能换兼容就arm64-v8,以兼容换性能armeabi,二者稍微平衡一点的就armeabi-v7a。

对于64位手机跟64位处理器

ARM64位处理器和电脑的64位处理器是两个截然不容的概念，他并不是64位就能原生向下兼容32位程序，而是通过64位处理器中集成的32位架构来运行32位程序。说得通俗点，它不是以64位形态来运行32位程序，却是以32位的形态运行32位程序的。

由于目前新出的64位处理器包含两个架构，而且制程技术没有提升（28nm），同时在手机与平板上，芯片面积有着严格的限定，不能过分增加，这导致64位ARM处理器平均分配到每个架构的晶体管数量锐减，也就是说从64位处理器中的32位架构方面，对于同规格的32位处理器而言，不但没有提高，性能反而是一定规模下降的。但处理器厂家又必须给消费者一个交代，以更好的推广64位，所以厂家就必须在其他方面提升性能，以弥补CPU的晶体管数量减少带来的损失。比如：更换性能更强的GPU、提升内存带宽、多核心虚拟单颗核心提升单核性能、联合跑分软件商修改跑分权重（提升GPU分数，降低CPU分数的权重）等等。这样，扬长避短，最终到达消费者手里，用跑分软件一跑，确实有提升，用户开心，厂家腰包也鼓了。

综上所述，ARM64位处理器从严格意义来说，叫它ARM32+64更加贴切，他相对于ARM32位处理器，有倒退的地方，也有进步的余地，但正因为倒退激起了ARM进取的决心，让它大刀阔斧的向前变革，不得不说也算一种进步。但ARM64在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的） 综上所述，ARM64位处理器从严格意义来说，叫它ARM32+64更加贴切，他相对于ARM32位处理器，有倒退的地方，也有进步的余地，但正因为倒退激起了ARM进取的决心，让它大刀阔斧的向前变革，不得不说也算一种进步。但ARM64在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的）

但是谷歌官方2019年初就已经发布强制需要64位架构：

早在今年(2019)一月份，Google 就发布通知，在今年 8 月 1 日开始，上架的 App，除了提供 32 位的版本之外，还需要提供 64 位的版本。

打包配置

split分包
这个命令可以按照各种规则去分包，比如按照abi,屏幕密度（即ldpi,hdpi等）分包

splits { 
    abi { 
    enable true reset() include 'x86','armabi' exclude 'armeabi', 'armeabi-v7a', "arm64-v8a" universalApk true } } 

include就是包括，exclude就是不包括。包括的配置每一个项都会生成一个apk包。

但是这样配置，会生成两个包，一个只包含x86的so库，一个只包含armabi的so库。，显然不符合需求

ndk{abiFilters:}过滤
这个指令可以配置只打包你配置的so库，没有配置的就不打包，很灵活。

第三方aar文件，如果这个sdk对abi的支持比较全，可能会包含armeabi、armeabi-v7a、x86、arm64-v8a、x86_64五种abi，而你应用的其它so只支持armeabi、armeabi-v7a、x86三种，直接引用sdk的aar，会自动编译出支持5种abi的包。但是应用的其它so缺少对其它两种abi的支持，那么如果应用运行于arm64-v8a、x86_64为首选abi的设备上时，就会crash了，所以我们需要在我们的app中配置 abiFilter 配置，来避免一些未知的错误

//过滤x86的so库 ndk { 
    abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a' } 

这样配置会将armeabi，armeabi-v71,arm64-v8a这3个包下的so库都打包到一个apk,而不像splits会每一个包打一个apk.

参考：
对于android cpu架构 ARM 和x86的区别 按照cpu架构分别打包Apk
Android 中arm64-v8a、armeabi-v7a、armeabi、x86简介~
https://juejin.im/post/5eae6f86e51d454ddb0b3dc6