1. 什么是CPU架构及ABI

Android系统目前支持以下七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。

应用程序二进制接口（Application Binary Interface）定义了二进制文件（尤其是.so文件）如何运行在相应的系统平台上，从使用的指令集、内存对齐到可用的系统函数库。在Android系统上，每一个CPU架构对应一个ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。

2. 为什么需要重点关注.so文件

如果项目中使用到了NDK，它将会生成.so文件，因此显然你已经在关注它了。如果只是使用Java语言进行编码，你可能在想不需要关注.so文件了吧，因为Java是跨平台的。但事实上，即使你在项目中只是使用Java语言，很多情况下，你可能并没有意识到项目中依赖的函数库或者引擎库里面已经嵌入了.so文件，并依赖于不同的ABI。例如，项目中使用RenderScript支持库，OpenCV，Unity，android-gif-drawable，SQLCipher等，你都已经在生成的APK文件中包含.so文件了，而你需要关注.so文件。

Android应用支持的ABI取决于APK中位于lib/ABI目录中的.so文件，其中ABI可能是上面说过的七种ABI中的一种。

Native Libs Monitor这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件，以及.so文件来源于哪些函数库或者框架。当然，我们也可以自己对APP反编译来获取这些信息，不过相对麻烦一些。

很多设备都支持多于一种的ABI，例如ARM64和x86设备也可以同时运行armeabi-v7a和armeabi的二进制包。但最好是针对特定平台提供相应平台的二进制包，这种情况下运行时就少了一个模拟层（例如x86设备上模拟arm的虚拟层），从而得到更好的性能（归功于最近的架构更新，例如硬件fpu，更多的寄存器，更好的向量化等）。我们可以通过Build.SUPPORTED_ABIS得到根据偏好排序的设备支持的ABI列表。但你不应该从你的应用程序中读取它，因为Android包管理器安装APK时，会自动选择APK包中为对应系统ABI预编译好的.so文件，如果在对应的lib/ABI目录中存在.so文件的话。

3. .so文件应该放在什么地方

我们往往很容易对.so文件应该放在或者生成到哪里感到困惑，下面是一个总结：

• Android Studio工程放在main/jniLibs/ABI目录中（当然也可以通过在build.gradle文件中的设置jniLibs.srcDir属性自己指定）
• Eclipse工程放在libs/ABI目录中（这也是ndk-build命令默认生成.so文件的目录）
• AAR压缩包中位于jni/ABI目录中（.so文件会自动包含到引用AAR压缩包的APK中）
• 最终APK文件中的lib/ABI目录中
• 通过PackageManager安装后，在小于Android 5.0的系统中，.so文件位于app的nativeLibraryPath目录中；在大于等于Android 5.0的系统中，.so文件位于app的nativeLibraryRootDir/CPU_ARCH目录中。

4. 安装Apk时PackageManagerService选择解压so文件的策略

在Android系统中，当我们安装Apk文件的时候，lib目录下的so文件会被解压App的原生库目录，一般来说是放到/data/data/package-name/lib目录下，而根据系统和CPU架构的不同，其拷贝策略也是不一样的，不正确地配置so文件，比如某些App使用第三方的so时，只配置了其中某一种CPU架构的so，可能会造成App在某些机型上的适配问题。

Android版本so拷贝策略策略问题< 4.0遍历Apk中文件，当Apk中lib目录下主abi子目录中有so文件存在时，则全部拷贝主abi子目录下的so；只有当主abi子目录下没有so文件的时候才会拷贝次abi子目录下的so文件。当so放置不当时，安装Apk时会导致拷贝不全。比如Apk的lib目录下存在armeabi/libx.so,armeabi/liby.so,armeabi-v7a/libx.so这3个so文件,那么在主abi为armeabi-v7a且系统版本小于4.0的手机上，Apk安装后，按照拷贝策略，只会拷贝主abi目录下的文件即armeabi-v7a/libx.so，当加载liby.so时就会报找不到so的异常。另外如果主abi目录不存在，这个策略会遍历2次Apk，效率偏低。4.0-4.0.3遍历Apk中所有文件，如果符合so文件的规则，且为主abi目录或者次abi目录下的so，就解压拷贝到相应目录。存在同名so覆盖，比如一个App的armeabi和armeabi-v7a目录下都包含同名的so，那么就会发生覆盖现象，覆盖的先后顺序根据so文件对应ZipFileR0中的hash值而定，考虑这样一个例子，假设一个Apk同时有armeabi/libx.so和armeabi-v7a/libx.so，安装到主abi为armeabi-v7a的手机上，拷贝so时根据遍历顺序，存在一种可能即armeab-v7a/libx.so优先遍历并被拷贝，随后armeabi/libx.so被遍历拷贝，覆盖了前者。本来应该加载armeabi-v7a目录下的so，结果按照这个策略拷贝了armeabi目录下的so。> 4.0.4遍历Apk中文件，当遍历到有主abi目录的so时，拷贝并设置标记hasPrimaryAbi为真，以后遍历则只拷贝主abi目录下的so，当标记为假的时候，如果遍历的so的entry名包含次abi字符串，则拷贝该so。经过实际测试，so放置不当时，安装Apk时存在so拷贝不全的情况。这个策略想解决的问题是在4.0~4.0.3系统中的so随意覆盖的问题，即如果有主abi目录的so则拷贝，如果主abi目录不存在这个so则拷贝次abi目录的so，但代码逻辑是根据ZipFileR0的遍历顺序来决定是否拷贝so，假设存在这样的Apk，lib目录下存在armeabi/libx.so, armeabi/liby.so, armeabi-v7a/libx.so这三个so文件，且hash的顺序为armeabi-v7a/libx.so在armeabi/liby.so之前，则Apk安装的时候liby.so根本不会被拷贝，因为按照拷贝策略，armeabi-v7a/libx.so会优先遍历到，由于它是主abi目录的so文件，所以标记被设置了，当遍历到armeabi/liby.so时，由于标记被设置为真，liby.so的拷贝就被忽略了，从而在加载liby.so的时候会报异常。64位分别处理32位和64位abi目录的so拷贝，abi由遍历Apk结果的所有so中符合bilist列表的最靠前的序号决定，然后拷贝该abi目录下的so文件。策略假定每个abi目录下的so都放置完全的，这是和4.0以前版本一样的处理逻辑，存在遗漏拷贝so的可能。

5. 配置so的建议

针对Android 系统的这些拷贝策略的问题，我们给出了一些配置so的建议：

5.1 针对armeabi和armeabi-v7a两种ABI

方法1：由于armeabi-v7a指令集兼容armeabi指令集，所以如果损失一些应用的性能是可以接受的，同时不希望保留库的两份拷贝，可以移除armeabi-v7a目录和其下的库文件，只保留armeabi目录；比如Apk使用第三方的so只有armeabi这一种ABI时，可以考虑去掉Apk中lib目录下armeabi-v7a目录。

方法2：在armeabi和armeabi-v7a目录下各放入一份so。

5.2 针对x86

目前市面上的x86机型，为了兼容arm指令，基本都内置libhoudini模块，即二进制转码支持，该模块负责把ARM指令转换为x86指令，所以如果是出于Apk包大小的考虑，并且可以接受一些性能损失，可以选择删掉x86库目录，x86下配置的armeabi目录的so库一样可以正常加载使用。

5.3 针对64位ABI

如果App开发者打算支持64位，那么64位的so要放全，否则可以选择不单独编译64位的so，全部使用32位的so，64位机型默认支持32位so的加载。比如Apk使用第三方的so只有32位ABI的so，可以考虑去掉Apk中lib目录下的64位ABI子目录，保证Apk安装后正常使用。

5. Android Studio配置abiFilters

android {
    defaultConfig {
        ndk {
            abiFilters 'armeabi-v7a' //, 'armeabi', 'arm64-v8a', 'x86', 'x86_64', 'mips', 'mips64'
        }
    }
}

这句话的意思就是指定NDK需要兼容的架构，把除了armeabi-v7a以外的兼容包都过滤掉，只剩下一个armeabi-v7a的文件夹。

即使我们没有指定其他的兼容框架，也需要一个过滤。当我们接入多个第三方库时，很可能第三方库做了多个平台的兼容。譬如fresco就做了各个平台的兼容，所以它创建了各个兼容平台的目录。因为只要出现了这个目录，系统就只会在这个目录里找.so文件而不会遍历其他的目录，所以就出现了找不到.so文件的情况。

6. java.lang.UnsatisfiedLinkError

该错误类型较多，以下进行分类:

• java.lang.UnsatisfiedLinkError : dlopen failed: library //dlopen打开失败
• java.lang.UnsatisfiedLinkError ：findLibrary returned null //找不到library
• java.lang.UnsatisfiedLinkError : Native method not found //找不到对应函数
• java.lang.UnsatisfiedLinkError ：Cannot load library: load_library //无法load library

出现原因：

显然出现上述崩溃的根本原因是：

（1）so无法加载，可能是so不存在等原因

（2）so正常加载，但是没有找到相应的函数

针对第二个原因，显然相对来说很容易排查，而且在开发中，这样的函数调用必然会在编译时和debug模式下进行测试，所以这种原因产生的概率很小。

那么下面主要总结几类“so无法加载”而导致上述崩溃的几种原因：

6.1 生成的so本身缺陷

一个简单的例子：

crash堆栈：

java.lang.UnsatisfiedLinkError: Cannot load library: find_library(linker.cpp:889): "/data/data/com.netease.nis.apptestunit/app_lib/libdemo.so" failed to load previously
 at java.lang.Runtime.load(Runtime.java:340)
 at java.lang.System.load(System.java:521)
 at com.netease.nis.bugrpt.ReLinker.loadLibrary(ReLinker.java:76)
 at com.example.crash.MainActivity.onCreate(MainActivity.java:272)
 at android.app.Activity.performCreate(Activity.java:5220)
 at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1086)
 at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2193)
 at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2279)
 at android.app.ActivityThread.access$600(ActivityThread.java:142)
 at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1272)
 at android.os.Handler.dispatchMessage(Handler.java:99)
 at android.os.Looper.loop(Looper.java:137)
 at android.app.ActivityThread.main(ActivityThread.java:5105)
 at java.lang.reflect.Method.invokeNative(Native Method)
 at java.lang.reflect.Method.invoke(Method.java:511)
 at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
 at dalvik.system.NativeStart.main(Native Method)

解决方法：

查看原项目Application.mk，发现APP_STL := gnustl_shared。原方案使用的是共享库，这不一定都支持所有的机型，改用静态库gnustl_static问题解决。
对应的在Android Studio中需要将共享库改用静态库gnustl_static。这一类关于so编译共享库问题，需要进行检查。

APP_STL 可用值

system  系统默认
stlport_static - 使用STLport作为静态库
stlport_shared - 使用STLport 作为共享库
gnustl_static  -  使用GNU libstdc++ 作为静态库
gnustl_shared -  使用GNU libstdc++ 作为共享库

上述例子只是一个简单的例子，可能在so编译生成时，由于没有考虑共享库的机型匹配等原因导致UnsatisfiedLinkError崩溃，其次是64位32位系统架构问题，也可能导致UnsatisfiedLinkError崩溃。

6.2 手机设备没有空间

在so正确生成情况下，会根据设置的支持so库框架生成对应的库。在Android系统中，当我们安装Apk文件的时候，lib目录下的so文件会被解压到App的原生库目录，一般来说是放到/data/data/package-name/lib目录下，当准备加载native层的so时，虽然在Apk中有对应的so文件，但是由于手机设备没有足够的空间加载该so，导致加载失败，产生上述崩溃。

6.3 so配置错误

倘若so正确生成，且手机空间充足，那么如上所述，在Android系统中，当我们安装Apk文件的时候，lib目录下的so文件会被解压到App的原生库目录，一般来说是放到/data/data/package-name/lib目录下。但是根据系统和CPU架构的不同，其拷贝策略也是不一样的。倘若不正确地配置了so文件,比如某些App使用第三方的so时，只配置了其中某一种CPU架构的so，可能会造成App在某些机型上的适配问题，产生上述崩溃。

6.4 Android的PackageManager安装问题

用户安装了与手机CPU架构不符的Apk安装包，或者App升级过程中因各种原因未正确释放so文件。这种问题可以使用ReLinker解决。

使用ReLinker十分简单，使用

ReLinker.loadLibrary(context, “mylibrary”)

代替标准的即可。

System.loadLibrary(“mylibrary”);

参考：

[1] http://www.kejik.com/article/21884.html

[2] http://blog.csdn.net/wove55678/article/details/52313208

[3] http://crash.163.com/index.do#news/!newsId=5

[4] http://blog.csdn.net/crash163/article/details/51895987

[5] http://crash.163.com/index.do#news/!newsId=4