ABI和CPU关系的疑难杂症
在这里非常感激腾讯bugly的“Bugly-Android_符号表-Jalen”，对我有很多启发和帮助
ABI和CPU的重要知识
1、 很多设备都支持多于一种的ABI。
2、 当一个应用安装在设备上，只有该设备支持的CPU架构对应的.so文件会被安装。
3、
| ABI目录（横向）和cpu（纵向） | armeabi | armeabi-v7a | arm64-v8a | mips | mips64 | x86 | x86_64 |
|---|---|---|---|---|---|---|---|
| ARMv5 | 支持 | ||||||
| ARMv7 | 支持 | 支持 | |||||
| ARMv8 | 支持 | 支持 | 支持 | ||||
| MIPS | 支持 | ||||||
| MIPS64 | 支持 | 支持 | |||||
| x86 | 支持（3） | 支持（2） | 支持（1） | ||||
| x86_64 | 支持 | 支持 | 支持 |
注意：上表格中的空白部分，是我不知道它是否支持，极有可能是不支持
解析： x86设备上，选择ABI的优先级
- libs/x86目录中如果存在.so文件的话，会被安装
- 如果不存在，则会选择armeabi-v7a中的.so文件
- 如果也不存在，则选择armeabi目录中的.so文件
x86设备能够很好的运行ARM类型函数库，但并不保证100%不发生crash，特别是对旧设备，因为是运行在x86设备上模拟arm的虚拟层上。
4、 64位设备（arm64-v8a, x86_64, mips64）能够运行32位的函数库，但是以32位模式运行，在64位平台上运行32位版本的ART和Android组件，将丢失专为64位优化过的性能（ART，webview，media等等）。
5、 最好是针对特定平台提供相应平台的二进制包，这种情况下运行时就少了一个模拟层（例如x86设备上模拟arm的虚拟层），从而得到更好的性能（归功于最近的架构更新，例如硬件fpu，更多的寄存器，更好的向量化等）。
6、 会安装优先级较高的ABI目录，则其它优先级较低的ABI目录（包括其它module中的ABI目录），都无法安装。例如：在cpu是ARMv7架构的手机上，如果检测到armeabi-v7a，就会选择安装armeabi-v7a，则armeabi下的文件，都无法安装了。
7、 相应的ABI二进制文件，要放进相应的ABI目录中
8、一般情况下不要简单得修改架构目录名
我们可以通过Build.SUPPORTED_ABIS得到根据偏好排序的设备支持的ABI列表。但你不应该从你的应用程序中读取它，因为Android包管理器安装APK时，会自动选择APK包中为对应系统ABI预编译好的.so文件，如果在对应的lib／ABI目录中存在.so文件的话。
工具
查看项目中ABI文件的架构类型
腾讯bugly，符号表工具，下载地址：http://bugly.qq.com/whitebookNative Libs Monitor这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件，以及.so文件来源于哪些函数库或者框架。
疑难杂症
虽然规则制定出来了，但总是会出现一些，不合规的现象，导致一些错误，难以理解。现在就让我们来一起把把脉，看看到底是什么疑难杂症
一、ABI二进制文件，放进了优先级低的ABI目录
一、如果你的项目中，有其他优先级更高的ABI目录，但是你把ABI文件放到了优先级低的目录，则你的ABI文件无法被加载
二、如果你的项目中，ABI文件放在了，项目中优先级最高的ABI目录中（这个ABI目录是手机所支持的在项目中优先级最高的，但不一定是手机所支持的优先级最高的），则这个ABI文件，可以被加载，加载为ABI目录的所表示的架构类型。
例子：
我的手机cpu架构是ARMv7，ABI文件是armeabi-v7a，但是放进了armeabi目录中
在运行的过程中会出现两种情况：
1、项目中有armeabi-v7a的目录，armeabi目录中的文件，无法被加载，运行后报错，出现如下log信息。
Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"2、项目中只有armeabi的目录，armeabi目录是该项目优先级最高的ABI目录（虽然armeabi目录在ARMv7所支持的优先级最高的ABI目录不是最高），作为armv5，安装到手机上。
二、ABI二进制文件，放进了优先级高的ABI目录
可以被加载使用，被加载为ABI文件所表示的结构类型
例子：
我的手机cpu架构是ARMv7，ABI文件是armeabi-v5te，但是放进了armeabi-v7a目录中。
可以被加载，但是加载为ABI文件所表示的架构类型。这样就出现了，同一个应用中ABI文件，出现两种的情况。
三、两个第三的SDK中ABI文件优先级不一样
问题：
两个第三方的SDK中ABI文件优先级不一样，手机加载运行时，会导致优先级低的库，无法被加载
例子：
我的手机cpu架构是ARMv7，项目中使用两个第三方SDK：企业A和企业B
企业A：ABI文件是armeabi-v7a，放进armeabi-v7a目录中。
企业B：ABI文件是armeabi-v5te，放进armeabi目录中。
在运行时，会发现运行后crash，出现如下log信息。
Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"解决办法：
1、使用同一优先级的ABI文件，ABI文件放入优先级相同的ABI目录
企业A：ABI文件是armeabi-v5te，放进armeabi目录中。
企业B：ABI文件是armeabi-v5te，放进armeabi目录中。
或
企业A：ABI文件是armeabi-v7a，放进armeabi-v7a目录中。
企业B：ABI文件是armeabi-v7a，放进armeabi-v7a目录中。
2、使用不同优先级的ABI文件，ABI文件放入优先级相同的ABI目录。一般情况不建议这么做。
企业A：ABI文件是armeabi-v7a，但是放进armeabi目录中。
企业B：ABI文件是armeabi-v5te，放进armeabi目录中。
或
企业A：ABI文件是armeabi-v7a，放进armeabi-v7a目录中。
企业B：ABI文件是armeabi-v5te，但是放进armeabi-v7a目录中。