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

最近在用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移除了，如图所示：

各版本分析如下：
• mips / mips64: 极少用于手机可以忽略（谷歌最新的文档已经不支持了）
• x86 / x86_64: x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现 对 arm .so 的兼容，再考虑 x86 1% 以下的市场占有率，x86 相关的两个 .so 也是可以忽略的
• armeabi: ARM v5 这是相当老旧的一个版本，缺少对浮点数计算的硬件支持，在需要大量计算时有性能瓶颈
• armeabi-v7a: ARM v7
• arm64-v8a: 64位支持，目前主流的版本，虽然网上很多博客都说v7是主流版本，但是我亲自试验了很多手机，都是arm64-v8a的架构，测试机型包括小米5-小米9，华为P30，华为mate10，魅蓝2等均是v8架构
查询手机cpu命令行：

adb shell getprop ro.product.cpu.abi

无图无真相：

只有一款不知名的oppo手机，android系统4.3，用的是v7的架构

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文件夹）找了，而是直接抛出异常。

我们项目中该如何适配呢

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。

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

真正的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位程序摆在你眼前，也无法安装。。

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

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

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