关于安卓so的兼容性的简单说明

armeabi、armeabi-v7a、mips、x86 、arm64-v8a如何理解？

ABI:指应用基于哪一种指令集来进行编译，ABI之前总共有四种，分别是armeabi、armeabi-v7a、mips、x86，它们都是表示cpu的类型，如今又有了arm64-v8a。

（注意：如下全部讨论不包括mips）

先说之前对于so的平台兼容处理方式吧。

之前安卓都是32位系统，运行的进程都是32位，理论上armeabi的so能够被全平台兼容，因此，理论上咱们能够只提供一个armeabi的so就能在全部cpu平台运行了。也就是说若是咱们引入了A和B两个库，其中A提供了全平台的armeabi、armeabi-v7a、x86三个so，而B只有一个armeabi的so，那么咱们能够把B的这个so复制到其余两个文件夹就能够被兼容了。

同时由于如今armeabi的设备比armeabi-v7的要少不少，因此有些应用直接提供了armeabi-v7的so。

如今有了arm64-v8a的CPU以及安卓64位系统，上面的方法就有点例外了。

在安卓64位系统上，同时运行着32位和64位的进程（这点和Windows很像，在64位Windows上也是能同时运行32位和63位的进程的）。

如下讨论是基于64位安卓系统上：

1. 若是一个纯粹的java写的应用，没有使用任何的so，那么默认就应该以64位模式来运行；

2. 若是一个应用中只提供了32位的so，那么这个应用会运行在32位模式，咱们以前的拷贝so到其余文件夹的方式依然是可行的。

3. 若是一个应用引入了两个库分别是A和B，其中A提供了armeabi，armeabi-v7，arm64-v8a，x86四个so，而B只提供了armeabi一个so，这样的话，由于应用启动时会检测到arm64-v8a的存在，因此就会以64位模式来运行了，这时须要用到的so必须为64位的，就不能使用armeabi的so来兼容了，也就是说一个进程中一旦使用了64位的so，那么就不能使用32位的so了，这点也和Windows很像。要解决这个问题，要么就是找到B的其余平台的so，要么就是去掉A的64位so，以32位模式来运行。