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

开始之前先需要知道lib、libs等知识
一. lib和libs
放在lib中的是被reference的，放在libs中的是被include的。
放在libs中的文件会自动被编辑器所include。所以不要把API放到libs里去。
lib的内容是不会被打包到APK中，libs中的内容是会被打包进APK中

二. .so库
NDK编译出来的动态链接库。
一些重要的加密算法或者核心协议一般都用c写然后给java调用。这样可以避免反编译后查看到应用的源码。

三. .so库该如何存放
放置 .so 文件的正确姿势其实就两句话：
• 为了减小 apk 体积，只保留 armeabi 和 armeabi-v7a 两个文件夹，并保证这两个文件夹中 .so 数量一致
• 对只提供 armeabi 版本的第三方 .so，原样复制一份到 armeabi-v7a 文件夹
存放so的规则：
你应该尽可能的提供专为每个ABI优化过的.so文件，但要么全部支持，要么都不支持：你不应该混合着使用。你应该为每个ABI目录提供对应的.so文件。
关于存放的问题，可以看看这篇
四. libs下armeabi等的作用是什么
存放.so库，主要针对不同的设备兼容，也可以说是专门针对不同Android手机下CPU架构的兼容。
下面就来扯一下安卓cpu
Android 设备的CPU类型(通常称为”ABIs”)

早期的Android系统几乎只支持ARMv5的CPU架构，后面发展到支持七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。
应用程序二进制接口（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集，内存对齐到可用的系统函数库。在Android 系统上，每一个CPU架构对应一个ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。
但是最新的谷歌官方文档已经把mips和armv5移除了，如图所示：

无图无真相：

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手机上的。

Q1： 只适配了armeabi-v7a,那如果APP装在其他架构的手机上，如arm64-v8a上，会蹦吗？
A: 不会，但是反过来会。
因为armeabi-v7a和arm64-v8a会向下兼容：

只适配armeabi的APP可以跑在armeabi,x86,x86_64,armeabi-v7a,arm64-v8上

只适配armeabi-v7a可以运行在armeabi-v7a和arm64-v8a

只适配arm64-v8a 可以运行在arm64-v8a上

那我们该如何适配呢？给出如下几个方案：
方案一：只适配armeabi

优点:基本上适配了全部CPU架构（除了淘汰的mips和mips_64）
缺点：性能低，相当于在绝大多数手机上都是需要辅助ABI或动态转码来兼容

方案二：只适配 armeabi-v7a
同理方案一，只是又筛掉了一部分老旧设备,在性能和兼容二者中比较平衡
方案三: 只适配 arm64-v8

优点: 性能最佳
缺点： 只能运行在arm64-v8上，要放弃部分老旧设备用户

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

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在的手机上真的有用吗？我只能说，目前确实没啥用，但今后或许有。（其他地方搜罗的）

真正的64位手机并不止单纯停留在处理器上，如果只因为它的处理器是64位，就称其为64位手机的话，我们可以毫不犹疑的说这可能是虚假宣传，好在联想很聪明，在发布A678t和A805e宣传的时候，只说64位处理器手机。
“64位处理器手机”与“64位手机”是两种天壤之别的概念：只要是处理器包含64架构位的，就可以称“64位处理器手机”，这种手机也许还运行不了64位程序，只是用来抢占市场，和32位手机比起来优势并不明显。

“64位手机”就不同了：它包含着64位处理器、64位标准系统、64位安卓虚拟机、以及64位程序，这才是真正意义上的64位手机！
谷歌官方曾说，安卓很早前就支持64位了，这话不假，从Android4.0到Android4.4，安卓系统都支持64位的硬件，但是这仅仅表示底层驱动支持64位，能运行在64位的硬件之上，仅此而已。然而，上层运行软件的，无论是Dalvik的虚拟机，还是ART虚拟机都是32位的。也就是说，只要你的手机系统是Android4.0—4.4，即便你的处理器是64位，也只能在32位虚拟机下运行32位程序，就算真的64位程序摆在你眼前，也无法安装。。

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

因此，项目之前强制只使用armeabi一种架构的方式已经不行了。
那这里说的 64 位版本支持，到底是什么？
如果你的应用，完全是使用 Java 或者 Kotlin 编写代码，不包含任何原生（Native）的支持，那么就表示这个应用已经支持 64 位。
但是应用内使用了任何原生（Native）的支持（so 库），就需要针对这些 so 文件，针对不同的 CPU 架构提供不同的版本的 so 支持。
需要注意的是，有些时候，在我们自身的代码中，确实没有用到原生的支持，但是在 App 中使用的一些第三方库中却包含了。
此时最稳妥的方式，就是针对最终打包生成的 APK 文件进行分析，来判断是否需要提供 64 位架构的支持。

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

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 配置，来避免一些未知的错误

这样配置会将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