Android开发中jni目录中arm－v64，armeabi－v7a，armeabi，x86，x86_64文件夹的意义

我们在开发应用的时候，尤其是加密算法，音视频编解码等时，会需要引入so库，文档上就会让我们创建arm－v64，armeabi－v7a，armeabi等文件夹，如下：



目前Android系统主持7种不同的CPU架构：ARMv5，ARMv7（从2010年起），x86（从2011年起），MIPs（从2012年起），ARMv8，MIPs64和x86-64（从2014年起），每一种都关联着一个相应的ABI。应用程序二进制接口（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集、内存对齐到可用的系统函数库。ABI和CPU的关系

很多设备都支持多于一种的ABI

当一个应用安装到设备上，只有该设备支持的CPU架构对应的.so文件会被安装

你应该尽可能的提供专为每个ABI优化过的.so文件，这种情况下运行时就少了一个模拟层（例如x86设备上模拟arm的模拟层），从而得到更好的性能。也就是我们需要创建上面图片上所有的文件夹，每个文件夹都对应一种相应的CPU架构。

对应关系为：

armeabi：第5代、第6代的ARM处理器

armeabi－v7a：第7代及以上的ARM处理器

arm64－v8a：第8代，64位的ARM处理器

x86：x86的处理器，平板，模拟器用的比较多

x86_64:64位的x86处理器

还有mips和mips64对应的分别是MIPs和MIPs64处理器，现在基本已经看不到了。

这样一来，就可以兼容所有机型，但我们的项目体积也会变得非常庞大。是否一定需要带入这么多SO文件去兼容呢？当然是否定的。

对于CPU来说，不同的架构并不意味着一定互不兼容，根据目前Android共支持七种不同类型的CPU架构，其兼容特点可总结如下：

armeabi设备只兼容armeabi；

armeabi-v7a设备兼容armeabi-v7a、armeabi；

arm64-v8a设备兼容arm64-v8a、armeabi-v7a、armeabi；

x86设备兼容x86、armeabi；

x86_64设备兼容x86_64、x86、armeabi；

mips64设备兼容mips64、mips；

mips只兼容mips；

但是兼容的不够智能，以一个arm64－v8a的cpu为例：

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

现在的手机cpu基本都是arm架构，想找到一个x86手机已经很费劲。mips指令集的手机就更不用说了，听说联想有出过，没见过。除非为了特殊需求，否则几乎可以不考虑单独编译带入x86、x86_64、mips、mips64架构SO文件。除去这四个架构之后，还要带入armeabi、armeabi-v7a、arm64-v8a这三个不同类型。为了减小APK体积，只保留armeabi和armeabi－v7a这两个文件夹就可以，毕竟arm64－v8a是可以向下兼容的，但这两个文件夹中so数量必须一致。当然简单粗暴只保留armeabi一个类型的文件也是可以，微信就是这么玩的，不过微信将性能差异比较明显的某个armeabi-v7a、arm64-v8a平台下的SO文件放到armeabi目录，然后通过代码判断设备的CPU类型，再加载其对应架构的SO文件。

科技在进步，现在市面上的手机很少有armeabi的，基本上是armeabi-v7a，或者64位的高端机器，所以我们就可以只保留armeabi-v7a架构的SO文件，这样就能获得更好的性能效果。

还有一个问题，只保留一个类型的文件，应用的so缺少对其它两种abi的支持，如果应用运行于arm64-v8a,x86_64为首选abi的设备上时，就会CRASH。 所以我们要把对x86, arm64-v8a,x86_64的支持去掉。

在build.gradle的defaultConfig内添加当前留下的类型:

ndk {
abiFilters "armeabi-v7a"
}

比如：