上周在做噪音检测so集成中，遇到不同的so库打包到 APK 时，安装在某些机器上，出现 java.lang.UnsatisfiedLinkError 加载失败。
为此，深究了一下原理，和给出了解决方案。
原理
Android 系统本质是一个经过改造的 Linux 系统。最早，Android 系统只支持 ARMv5 的 CPU 构架，随着 Android 系统的发展，又加入了 ARMv7 (2010), x86 (2011), MIPS (2012), ARMv8, MIPS64 和 x86_64 (2014)。
每一种 CPU 构架，都定义了一种 ABI（Application Binary Interface），ABI 决定了二进制文件如何与系统进行交互。
当你的 APP 中用到了些包含 SO 库第三方库，或者自己使用 NDK 来实现了某些功能，你就需要认真阅读接下来的教程。
NDK SO 支持不同的 CPU 构架
在使用 NDK 开发包含 c/c++ 代码的 SO 库的时候，你可以选择输出支持如下 ABI CPU 构架：
armeabi
armeabiv7a
arm64v8a
x86
x86_64
mips
mips64
NDK 库支持如上所有的 CPU 构架：
但不是所有人的开发者提供的 NDK 库都支持所有的 CPU 构架：
上面的这个开发者提供的库，就只支持 armeabi。
其实一般情况下，是没有问题的，x86 的设备，也会兼容 armeabi 的 so 库。
合并打包到 APK 中
如果不做任何设置，Android 的构建系统会把这些来自不同开发者的 SO 库都合并在一起，打进 APK 压缩包中。
【假设你的so是手动添加的，只提供了 armeabi 和 armeabi-v7a ，则构建时也会默认创建mips、mips64、x86等文件夹，而这些文件夹中其实是没有so文件，
当将apk安装到x86的系统中，应用程序会去x86文件夹查找so，如果没有找到则会出现异常 】
├── AndroidManifest.xml
├── classes.dex
├── lib
│ ├── arm64-v8a
│ │ └── libBugtags.so
│ ├── armeabi
│ │ ├── libhyphenate.so
│ │ └── libBugtags.so
│ ├── armeabi-v7a
│ │ └── libBugtags.so
│ ├── mips
│ │ └── libBugtags.so
│ ├── mips64
│ │ └── libBugtags.so
│ ├── x86
│ │ └── libBugtags.so
│ └── x86_64
│ └── libBugtags.so
├── res
系统安装 APK
根据官方 ndk-abi 文档， Android 系统在安装一个 APK 的时候，会考虑当前的设备的 CPU 构架和配置（称为所谓的 primary-abi 和 secondary-abi），去该 APK 文件的对应文件夹去寻找 SO 库。
假设当前设备是 x86 机器，会优先去 lib/x86 文件夹下寻找 SO 库：
lib/<primary-abi>/lib<name>.so
如果找不到，同时定义了 secondary-abi，则去如下文件夹寻找：
lib/<secondary-abi>/lib<name>.so
如果找到了，就将文件拷贝到 APK 的安装目录的如下文件夹中：
/lib/lib<name>.so
找不到对应的 SO，安装正常，但是当这个 SO 在运行时被使用时，会崩溃。
问题来了
可能你已经发现问题了，当一个 APK 是这种情况：
├── AndroidManifest.xml
├── classes.dex
├── lib
│ ├── arm64-v8a
│ │ └── libBugtags.so
│ ├── armeabi
│ │ ├── libhyphenate.so
│ │ └── libBugtags.so
│ ├── armeabi-v7a
│ │ └── libBugtags.so
│ ├── mips
│ │ └── libBugtags.so
│ ├── mips64
│ │ └── libBugtags.so
│ ├── x86
│ │ └── libBugtags.so
│ └── x86_64
│ └── libBugtags.so
├── res
同时 APK 被安装到一个 x86 的设备上的时候，以上的寻找过程，将会失败，运行时，将出现如下报错：
D/xxx (10674): java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/xxx-2/base.apk"],nativeLibraryDirectories=[/data/app/xxx-2/lib/x86, /vendor/lib, /system/lib]]] couldn't find "libirdna_sdk.so"
D/xxx (10674): at java.lang.Runtime.loadLibrary(Runtime.java:366)
此处，笔者有点费解，既然在 x86 文件夹中找不到，应该去 armeabi 文件夹中自动寻找啊，此处原因不明，可能要去确认是否是某些机器的原因。
解决方案
准则
NDK SO 开发者应该遵循一个准则：支持所有的平台，否则将会搞砸你的用户。
NDK SO 使用者应该遵循一个准则：要么支持所有平台，要么都不支持。
然而，事与愿违，因为种种原因（遗留 SO、芯片市场占有率、APK 包大小等），并不是所有人都遵循这样的原则。
折中方案
Android Studio
- Android Gradle 插件中，可以使用如下方式对 abi 进行过滤：
android {
...
defaultConfig {
...
ndk {
// 设置支持的 SO 库构架，注意这里要根据你的实际情况来设置
abiFilters 'armeabi'// 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64', 'mips', 'mips64'
}
}
}
关键行：
abiFilters 'armeabi'// 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64', 'mips', 'mips64'
根据你的 APP 中使用的 SO 库所支持的构架具体情况，你可以进行具体设置。最终输出的 apk 中，将会包含你所选择的 abi。
像前面举出的例子，就应该只允许 armeabi。
- 如果在添加 “abiFilter” 之后 Android Studio 出现以下提示：
NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin
则在项目根目录的 gradle.properties 文件中添加：
android.useDeprecatedNdk=true