最近在用flutter打包的时候，遇到了包打不出来的情况，后面查了半天原因，发现是没有配置arm导致的，配了之后就打出来了，乘着这个契机，重头来学习了一下abi
开始之前
开始之前先需要知道lib、libs等知识
一. lib和libs
放在lib中的是被reference的，放在libs中的是被include的。
放在libs中的文件会自动被编辑器所include。所以不要把API放到libs里去。
lib的内容是不会被打包到APK中，libs中的内容是会被打包进APK中
二. .so库
NDK编译出来的动态链接库。
一些重要的加密算法或者核心协议一般都用c写然后给java调用。这样可以避免反编译后查看到应用的源码。
架构介绍
早期的Android系统几乎只支持ARMv5的CPU架构，后面发展到支持七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS和x86_ (从2014年起)，每一种都关联着一个相应的ABI。
应用程序二进制接口（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集，内存对齐到可用的系统函数库。在Android 系统上，每一个CPU架构对应一个ABI：armeabi，armeabi-v7a，x86，mips，arm- v8a，mips，x86_。
但是最新的谷歌官方文档已经把mips和armv5移除了，如图所示：
adb shell getprop ro.product.cpu.abi
无图无：
ABI是如何工作的
2020.06更新， 看到一篇很好的文章搬过来了，感谢原作者（）
官方文档解释如下：
Android 系统在运行时知道它支持哪些 ABI，因为版本特定的系统属性会指示：
- 设备的主要 ABI，与系统映像本身使用的机器代码对应。
- （可选）与系统映像也支持的其他 ABI 对应的辅助 ABI。
此机制确保系统在安装时从软件包提取最佳机器代码。
为实现最佳性能，应直接针对主要 ABI 进行编译。例如，基于 ARMv5TE 的典型设备只会定义主 ABI：armeabi。相反，基于 ARMv7 的典型设备将主 ABI 定义为 armeabi-v7a，并将辅助 ABI 定义为 armeabi，因为它可以运行为每个 ABI 生成的应用原生二进制文件。
位设备也支持其 32 位变体。以 arm-v8a 设备为例，该设备也可以运行 armeabi 和 armeabi-v7a 代码。但请注意，如果应用以 arm-v8a 为目标，而非依赖于运行 armeabi-v7a 版应用的设备，则应用在 位设备上的性能要好得多。
许多基于 x86 的设备也可运行 armeabi-v7a 和 armeabi NDK 二进制文件。对于这些设备，主 ABI 将是 x86，辅助 ABI 是 armeabi-v7a。
总的来说，就是一个Android设备可以支持多种ABI,设备主ABI和辅助ABI,以arm-v8a为主ABI的设备，辅助ABI为armeabi-v7a和armeabi，以armeabi-v7a为主ABI的设备，辅助ABI为armeabi。
另外，x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现对 arm .so 的兼容，也就是说有适配armeabi平台的APP是可以跑在x86手机上的。
ABI具体适配流程
我们项目中该如何适配呢
Q1： 只适配了armeabi-v7a,那如果APP装在其他架构的手机上，如arm-v8a上，会蹦吗？
A: 不会，但是反过来会。
因为armeabi-v7a和arm-v8a会向下兼容：
- 只适配armeabi的APP可以跑在armeabi,x86,x86_,armeabi-v7a,arm-v8上
- 只适配armeabi-v7a可以运行在armeabi-v7a和arm-v8a
- 只适配arm-v8a 可以运行在arm-v8a上
那我们该如何适配呢？给出如下几个方案：
方案一：只适配armeabi
优点:基本上适配了全部CPU架构（除了淘汰的mips和mips_）
缺点：性能低，相当于在绝大多数手机上都是需要辅助ABI或动态转码来兼容
方案二：只适配 armeabi-v7a
同理方案一，只是又筛掉了一部分老旧设备,在性能和兼容二者中比较平衡
方案三: 只适配 arm-v8
优点: 性能最佳
缺点： 只能运行在arm-v8上，要放弃部分老旧设备用户
这三种方案都是可以的，现在的大厂APP适配中，这三种都有，大部分是前2种方案。具体选哪一种就看自己的考量了，以性能换兼容就arm-v8,以兼容换性能armeabi,二者稍微平衡一点的就armeabi-v7a。
对于位位处理器
ARM位处理器和电脑的位处理器是两个截然不容的概念，他并不是位就能原生向下兼容32位程序，而是通过位处理器中集成的32位架构来运行32位程序。说得通俗点，它不是以位形态来运行32位程序，却是以32位的形态运行32位程序的。
由于目前新出的位处理器包含两个架构，而且制程技术没有提升（28nm），同时在手机与平板上，芯片面积有着严格的限定，不能过分增加，这导致位ARM处理器平均分配到每个架构的晶体管数量锐减，也就是说从位处理器中的32位架构方面，对于同规格的32位处理器而言，不但没有提高，性能反而是一定规模下降的。但处理器厂家又必须给消费者一个交代，以更好的推广位，所以厂家就必须在其他方面提升性能，以弥补CPU的晶体管数量减少带来的损失。比如：更换性能更强的GPU、提升内存带宽、多核心虚拟单颗核心提升单核性能、联合跑分软件商修改跑分权重（提升GPU分数，降低CPU分数的权重）等等。这样，扬长避短，最终到达消费者手里，用跑分软件一跑，确实有提升，用户开心，厂家腰包也鼓了。
综上所述，ARM位处理器从严格意义来说，叫它ARM32+更加贴切，他相对于ARM32位处理器，有倒退的地方，也有进步的余地，但正因为倒退激起了ARM进取的决心，让它大刀阔斧的向前变革，不得不说也算一种进步。但ARM在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的） 综上所述，ARM位处理器从严格意义来说，叫它ARM32+更加贴切，他相对于ARM32位处理器，有倒退的地方，也有进步的余地，但正因为倒退激起了ARM进取的决心，让它大刀阔斧的向前变革，不得不说也算一种进步。但ARM在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的）
真正的位手机并不止单纯停留在处理器上，如果只因为它的处理器是位，就称其为位手机的话，我们可以毫不犹疑的说这可能是虚假宣传，好在联想很聪明，在发布A678t和A805e宣传的时候，只说位处理器手机。
“位处理器手机”与“位手机”是两种天壤之别的概念：只要是处理器包含架构位的，就可以称“位处理器手机”，这种手机也许还运行不了位程序，只是用来抢占市场，和32位手机比起来优势并不明显。
“位手机”就不同了：它包含着位处理器、位标准系统、位安卓虚拟机、以及位程序，这才是真正意义上的位手机！
谷歌官方曾说，安卓很早前就支持位了，这话不假，从Android4.0到Android4.4，安卓系统都支持位的硬件，但是这仅仅表示底层驱动支持位，能运行在位的硬件之上，仅此而已。然而，上层运行软件的，无论是Dalvik的虚拟机，还是ART虚拟机都是32位的。也就是说，只要你的手机系统是Android4.0—4.4，即便你的处理器是位，也只能在32位虚拟机下运行32位程序，就算真的位程序摆在你眼前，也无法安装。。
但是谷歌官方今年年初就已经发布强制需要位架构：
因此，项目之前强制只使用armeabi一种架构的方式已经不行了。
那这里说的 位版本支持，到底是什么？
如果你的应用，完全是使用 Java 或者 Kotlin 编写代码，不包含任何原生（Native）的支持，那么就表示这个应用已经支持 位。
但是应用内使用了任何原生（Native）的支持（so 库），就需要针对这些 so 文件，针对不同的 CPU 架构提供不同的版本的 so 支持。
需要注意的是，有些时候，在我们自身的代码中，确实没有用到原生的支持，但是在 App 中使用的一些第三方库中却包含了。
此时最稳妥的方式，就是针对最终打包生成的 APK 文件进行分析，来判断是否需要提供 位架构的支持。
打包配置
split分包
这个命令可以按照各种规则去分包，比如按照abi,屏幕密度（即ldpi,hdpi等）分包
splits {
abi {
enable true
reset()
include 'x86','armabi'
exclude 'armeabi', 'armeabi-v7a', "arm-v8a"
universalApk true
}
}
include就是包括，exclude就是不包括。包括的配置每一个项都会生成一个apk包。
但是这样配置，会生成两个包，一个只包含x86的so库，一个只包含armabi的so库。，显然不符合需求
ndk{abiFilters:}过滤
这个指令可以配置只打包你配置的so库，没有配置的就不打包，很灵活。
第三方aar文件，如果这个sdk对abi的支持比较全，可能会包含armeabi、armeabi-v7a、x86、arm-v8a、x86_五种abi，而你应用的其它so只支持armeabi、armeabi-v7a、x86三种，直接引用sdk的aar，会自动编译出支持5种abi的包。但是应用的其它so缺少对其它两种abi的支持，那么如果应用运行于arm-v8a、x86_为首选abi的设备上时，就会crash了，所以我们需要在我们的app中配置 abiFilter 配置，来避免一些未知的错误
//过滤x86的so库
ndk {
abiFilters 'armeabi', 'armeabi-v7a', 'arm-v8a'
}
这样配置会将armeabi，armeabi-v71,arm-v8a这3个包下的so库都打包到一个apk,而不像splits会每一个包打一个apk.
参考：
