Android中的ABI

Android中的CPU

表中的数字表示最终选择安装的ABI的优先级，1为最高。

应用安装到设备时，只有该设备的CPU架构支持的最优so库才会被安装。

如：x86架构的设备支持x86、armeabi-v7a和armeabi等ABI。但优先级从高到低依次为x86、armeabi-v7a、armeabi。系统会根据此顺序寻找首个可用的最优的so库，找到则结束。
x86设备包含ARM模拟层，能够很好地运行ARM类型的so库，但并不保证100%不发生Crash。
64位设备（arm64-v8a, x86_64, mips64）能够运行32位的so库。但是以32位模式运行时，会丢失专为64位优化过的性能特征（ART, WebView, Media, etc.）。

在Android Studio中的路径：

默认要放在模块/src//jniLibs//下。如：将so库放在app/src/main/jniLibs/armeabi。

可在模块的build.gradle中修改配置指定so库的路径。如，将so库放在app/libs/armeabi下，并修改配置如下：

 android {  ...  sourceSets {    main {      jniLibs.srcDirs = ['libs']    }  }}

System.loadLibrary("so库的名称");如System.loadLibrary("daking");会加载该应用下的libdaking.so文件。
System.load("so库文件的全路径");如System.load("/data/data/com.daking.app.demo/libdaking.so");会加载包名为com.daking.app.demo的应用的libdaking.so文件。

理论上应该为每个ABI目录提供对应的so库。但是Android支持7种ABI，若全部支持，必然导致APK包过大。
一般只保留armeabi、armeabi-v7a这两个ABI的so库。

mips/mips64：极少用于手机，可忽略。

x86/x86_64：x86架构的手机的市场占有率很低，约为1%左右。而且x86架构都包含ARM模拟层，兼容ARM类型的ABI。注意，模拟器为x86架构。

arm64-v8a：64位ARM架构。可用32位模式运行armeabi-v7a和armeabi。

armeabi-v7a：截止于2017年2月，目前主流版本AMRv7。

armeabi：老版本ARMv5，但仍需要兼容。
通过上面的分析，不难发现，只要提供armeabi便可兼容新/旧设备。但armeabi缺少对浮点数机器的支持，存在性能瓶颈。应该将armeabi目录中的so库拷贝一份到armeabi-v7a目录中。
总结：

为了减小apk体积，只保留armeabi和armeabi-v7a两个目录，并保证这两个目录中so库数量一致。

对只提供armeabi版本的第三方so库，原样复制一份到armeabi-v7a目录中。

使用高版本编译出的so库运行在低版本的平台上会出错。考虑到NDK是向前兼容的，应使用低版本编译。
so库放置的路径有误。
没有在每个生效的ABI目录下放置对应的so库。
1. 若某应用有armeabi和arm64-v8a两个ABI目录，armeabi目录里有a.so和b.so，但arm64-v8a只有a.so。
2. 当ARMv8设备在安装此应用时，根据ABI优先级，首先发现arm64-v8a目录存在，并决定使用此ABI下的so库。
3. 但arm64-v8a目录中没有b.so，于是报错。
4. 此时的解决方案有：一，删除arm64-v8a目录；二，arm64-v8a目录的so库情况要与armeabi一致。

我的博客