关于so的兼容问题，算是老生常谈了，如果你做Android开发有过几年的经验的话，可能早就熟知这个问题了。本文做一个简要的整理记录，方便查阅。
| ABI | 说明 | 兼容手机 |
|---|---|---|
| armeabi | ARM v5 第5代、第6代的ARM处理器， 早期的手机用的比较多， 缺少对浮点数计算的硬件支持， 在需要大量计算时有性能瓶颈 |
几乎能兼容所有机型 |
| armeabi-v7a | ARM v7第7代及以上的 ARM 处理器。 2011年15月以后的生产的大部分Android设备都使用它 |
目前主流手机都兼容 |
| arm64-v8a | 第8代、64位ARM处理器，支持更大的寻址空间 | 国内最近几年的知名手机厂商生产的 手机几乎都是64位处理器的 |
| x86 | x86架构的手机都会包含由 Intel 提供的称为 Houdini 的 指令集动态转码工具，实现 对 arm.so 的兼容 |
x86架构的手机市场占有率极低， 平板用得比较多 |
| x86_64 | x86架构的64位支持 | x86架构的手机市场占有率极低 |
| mips/mips64 | 极少用于手机 | 极少手机 |
关于so放置不当会导致的出错这里不列举了，这里总结一下避免出错的结论：
- 最好的方案是为每一个你想要支持的ABI版本提供对应的so文件，且每个文件夹中的so数量一致
- 为了减小 apk 体积，可以只保留 armeabi 和 armeabi-v7a 两个文件夹，并保证这两个文件夹中 .so 数量一致
- 如果app中已经有 armeabi-v7a文件，对只提供 armeabi 版本的第三方 .so，原样复制一份到 armeabi-v7a 文件夹, 这是由于 ARM v7 是前向兼容 ARM v5 的
- 只保留 armeabi文件夹里的so文件，因为所有的x86/x86_64/armeabi-v7a/arm64-v8a设备都支持armeabi架构的.so文件，这也是现在大多数主流app采取的为了减少apk体积同时保证兼容性的权衡方案
- 如果项目当中依赖了过多的第三方lib，不知道各个lib中的so情况，可以在生成apk之后解压apk文件查看有哪些ABI的so文件，并使用下面的方式过滤掉你不需要的so版本（但前提是要保证剩余的文件夹里so够用且数量一致）
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}
packagingOptions {
//exclude "lib/armeabi/*.so"
exclude "lib/armeabi-v7a/*.so"
exclude "lib/arm64-v8a/*.so"
}更多参考：