缘起
最近在项目中用到了realm，引起项目编译找不到so库，原来是realm的多版本so库所导致的。所以，解铃还须系铃人，咱们就从ABI入手解决这个问题。
ABI是什么
应用程序二进制接口ABI（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集，内存对齐到可用的系统函数库。在Android 系统上，每一个CPU架构对应一个ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。分别对应着下面7种CPU架构ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。
.so文件
.so文件是unix的动态连接库，是二进制文件，在Android中调用动态库文件(*.so)都是通过jni的方式，这里我们要说说NDK，Android NDK是一个工具集，它让我们能够在Android应用程序中使用由本地代码（native code）编写的代码模块，NDK 提供的编译系统让我们可以高效的编译源码，不需要去处理工具链、平台等细节。我们只需要创建很短的编译文件，描述哪些源文件要编译以及哪些应用程序会使用 它们，编译系统就会编译源代码并且将编译生成的共享库（shared libraries）直接放到我们的应用程序中。如果项目中使用到了NDK，它将会生成.so文件，因此显然你已经在关注它了。如果只是使用Java语言进行编码，你可能在想不需要关注.so文 件了吧，因为Java是跨平台的。但事实上，即使你在项目中只是使用Java语言，很多情况下，你可能并没有意识到项目中依赖的函数库或者引擎库里面已经 嵌入了.so文件，并依赖于不同的ABI，Android应用支持的ABI取决于APK中位于lib/ABI目录中的.so文件。Native Libs Monitor这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件，以及.so文件来源于哪些函数库或者框架。
当然，我们也可以自己对app反编译来获取这些信息，不过相对麻烦一些，其实我们只要把APK文件解压了以后就可以看到项目用到了哪些.so文件了。如下图
ABI和CPU的关系
很多设备都支持多于一种的ABI。例如ARM64和x86设备也可以同时运行armeabi-v7a和armeabi的二进制包。但最好是针对特 定平台提供相应平台的二进制包，这种情况下运行时就少了一个模拟层（例如x86设备上模拟arm的虚拟层），从而得到更好的性能（归功于最近的架构更新， 例如硬件fpu，更多的寄存器，更好的向量化等）。
我们可以通过Build.SUPPORTED_ABIS得到根据偏好排序的设备支持的ABI列表。但你不应该从你的应用程序中读取它，因为 Android包管理器安装APK时，会自动选择APK包中为对应系统ABI预编译好的.so文件，如果在对应的lib／ABI目录中存在.so文件的 话。
对应关系如下图：
配置.so文件
使用 app源根文件夹下build.gradle文件的配置：
android {
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "com.dygsm.dywifi"
minSdkVersion 15
targetSdkVersion 22
versionCode 1
versionName "04.30.00.01"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
// 不声明ndk标签,项目默认会创建一个libapp.so的文件
ndk {
abiFilters "armeabi", "armeabi-v7a", "x86"
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
此外，要在 gradle.properties 文件中添加android.useDeprecatedNdk=true，重新编译工程即可。
不同CPU架构的Android手机加载时会在libs下找自己对应的目录，从对应的目录下寻找需要的.so文件；如果没有对应的目录，就会去armeabi下去寻找，如果已经有对应的目录，但是如果没有找到对应的.so文件，也不会去armeabi下去寻找了。 所以，这里需要注意工程配置哪几个so文件目录，需要加载对应的so文件，不然会报错。
如何适配各个目录，例如有一些第三方的类库只提供了armeabi下的.so文件，而工程配置不止armeabi一个目录，这就需要将armeabi下的.so文件复制到其他对应的目录下。果第三方提供了不同平台的.so文件，则复制不同平台的.so文件到项目中对应的文件夹下即可。
so文件也会影响编译出的apk大小（将apk解压出来，lib目录下就为so文件目录），所以只配置armeabi一个目录，既能适配各CPU架构的手机，也能精简apk大小（微信就是只有armeabi一个目录）。
使用原则
你应该尽可能的提供专为每个ABI优化过的.so文件，你不应该混合着使用（不能就装对不同cpu架构的so文件，放在同一个ABI目录下）。你应该为每个ABI目录提供对应的.so文件。
当只有一个.so文件时，静态编译C++运行时是没问题的，
当存在多个.so文件时，应该让所有的.so文件都动态链接相同的C++运行时。
这意味着当引入一个新的预编译.so文件，而且项目中还存在其他的.so文件时，我们需要首先确认新引入的.so文件使用的C++运行时是否和已经存在的.so文件一致。
缘灭
缘起的时候出现的编译错误解决方法如下：
- 不使用realm。
- 在每个ABI文件下面复制相同的.so库。
- 适配的使用库运行和支持运行。
