一、前言

Android中有时候为了效率以及平台开发库的支持，难免会用到NDK开发，那么都会产生一个so文件，通过native方法进行调用，开发和调用步骤很简单，这里就不多说了，本文主要来介绍，我们在使用so的时候总是会出现一些常见的问题，而现在插件化开发也很普遍了，有时候插件中也会包含一些so文件，需要加载，这时候也会出现一些问题。本文就来详细总结一下这些问题出现的原因，以及解决方法，主要还是通过源码来分析。

二、涉及到的源码类

因为本文主要通过分析源码来分析so使用的知识点和问题总结，所以涉及到了很多的源码类，这里就现提供一下：

1、PackageManagerService.java
+setNativeLibraryPaths：设置应用的native库路径
+scanPackageDirtyLI：扫描包内容初始化应用信息

2、ActivityManagerService.java
+startProcessLocked：发送命令给Zygote进程启动一个虚拟机

3、NativeLibraryHelper.java

底层实现类：com_android_internal_content_NativeLibraryHelper.cpp

+copyNativeBinariesWithOverride：释放apk中的so文件到本地目录

+findSupportedAbi：遍历apk中的so文件结合abiList值得到应用支持的abi类型索引值

4、LoadApk类和ApplicationLoaders类

5、VMRuntime.java

底层实现类：dalvik_system_VMRuntime.c

+getInstructionSet：获取虚拟机的指令集类型

+is64BitAbi：判断VM是否为64位

6、Runtime.java

底层实现类：dalvik/vm/native/java_lang_Runtime.cpp，dalvik/vm/Native.cpp

+nativeLoad：加载so文件

三、Android中so文件的编译平台

Android中在进行NDK开发的时候，都知道因为机型杂而多的原因，没有一个大的标准，所以很多厂商都会采用不同型号的cpu，那么在编译so文件的时候，就需要进行交叉编译出多个cpu平台版本，现在主流的cpu架构版本：

armeabi/armeabi-v7a：这个架构是arm类型的，主要用于Android4.0之后的，cpu值32位的

x86/x86_64：这个架构是x86类型的，有32位和64位，占用的设备比例比较小

arm64-v8：这个架构是arm类型，主要用于Android5.0之后，cpu是64位的

这里可以看到，其中arm类型的是往下兼容策略，比如arm64-v8a肯定兼容armeabi/armeabi-v7a，也就是说armeabi/armeabi-v7a架构的so文件可以用在arm64-v8a的设备中的，而armeabi-v7a也是兼容armeabi的，但是因为cpu型号不同，所以arm体系和x86体系之间是不能相互兼容的。

四、Android中so加载流程

在Android中如果想使用so的话，首先得先加载，加载现在主要有两种方法，一种是直接System.loadLibrary方法加载工程中的libs目录下的默认so文件，这里的加载文件名是xxx，而整个so的文件名为：libxxx.so。还有一种是加载指定目录下的so文件，使用System.load方法，这里需要加载的文件名是全路径，比如：xxx/xxx/libxxx.so。

上面的两种加载方式，在大部分场景中用到的都是第一种方式，而第二种方式用的比较多的就是在插件中加载so文件了。

不管是第一种方式还是第二种方式，其实到最后都是调用了Runtime.java类的加载方法doLoad：

这里会先从类加载中获取到nativeLib路径，然后在调用native方法nativeLoad(java_lang_Runtime.cpp)：

这里调用了一个核心的方法dvmLoadNativeCode(dalvik/vm/Native.cpp)：

注意：

这里有一个检测异常的代码，而这个错误，是我们在使用插件开发加载so的时候可能会遇到的错误，比如现在我们使用DexClassLoader类去加载插件，但是因为我们为了插件能够实时更新，所以每次都会赋值新的DexClassLoader对象，但是第一次加载so文件到内存中了，这时候退出程序，但是没有真正意义上的退出，只是关闭了Activity了，这时候再次启动又会赋值新的加载器对象，那么原先so已经加载到内存中了，但是这时候是新的类加载器那么就报错了，解决办法其实很简单，主要有两种方式：

第一种方式：在退出程序的时候采用真正意义上的退出，比如调用System.exit(0)方法，这时候进程被杀了，加载到内存的so也就被释放了，那么下次赋值新的类加载就在此加载so到内存了，

第二种方式：就是全局定义一个static类型的类加载DexClassLoader也是可以的，因为static类型是保存在当前进程中，如果进程没有被杀就一直存在这个对象，下次进入程序的时候判断当前类加载器是否为null，如果不为null就不要赋值了，但是这个方法有一个弊端就是类加载器没有从新赋值，如果插件这时候更新了，但是还是使用之前的加载器，那么新插件将不会进行加载。

继续往下看：

这里主要调用了两个核心的系统方法，dlopen和dlsym，这两个方法用途还是很多的，一般是先加载so文件，然后得到指定函数的指针，最后直接调用即可，主要用于调用动态的调用so中的指定函数功能。而且这里注意到了最开始先调用so中的JNI_OnLoad函数，这个函数是so被加载之后调用的第一个方法。

到这里我们就总结一下Android中加载so的流程：

1、调用System.loadLibrary和System.load方法进行加载so文件

2、通过Runtime.java类的nativeLoad方法进行最终调用，这里需要通过类加载器获取到nativeLib路径。

3、到底层之后，就开始使用dlopen方法加载so文件，然后使用dlsym方法调用JNI_OnLoad方法，最终开始了so的执行。

五、Android中类加载器关联so路径

上面分析so加载过程中可以发现有一个地方，就是通过类加载器来获取到so的路径，那么Android中的主要类加载器有两个，一个是PathClassLoader和DexClassLoader，关于这两个类加载不多说了，网上资料很多可以自行查找阅读。而PathClassLoader是我们Android中默认的类加载器，也就是apk文件就是由他来加载的，我们可以通过查看源码得知，Android中加载apk的类加载可以从LoadApk.java类查找到：

注意：

这个类很重要的，而这个类加载器也是我们在做插件的时候，需要做一些操作，比如需要把加载插件的DexClassLoader类给添加到这个系统加载器中，就可以解决插件中组件的生命周期问题。

看看这个类加载器在哪里赋值的：

去看看ApplicationLoaders.java类：

看到了，这里就是定义了PathClassLoader类了，所以我们Android中应用的默认加载器是PathClassLoader，再去看看这个类加载器的nativeLib是哪里：

六、Android中so文件如何释放

我们在使用System.loadLibrary加载so的时候，传递的是so文件的libxxx.so中的xxx部分，那么系统是如何找到这个so文件然后进行加载的呢？这个就要先从apk文件安装时机说起。

我们如果还没有分析源码之前，大致能够猜想到的流程是：

在安装apk的时候，系统解析apk文件，因为so文件肯定是存放在libs下指定平台目录中的，而apk文件本身就是一个压缩文件，所以可以进行解压，然后读取libs目录下的so文件，进行本地释放解压到指定目录，然后在加载的时候就先拼接so文件的全路径，最后在进行加载工作即可。

通过猜想，下面就通过源码来分析一下流程，系统在安装apk的时候，是调用系统类：PackageManagerService.java类：

主要的核心方法是scanPackageDirtyLI：

这个方法主要通过传递的pkg变量，开始构造applicationInfo信息。我们往下面看，找到设置nativeLib信息的代码：

这里注意有一个判断，是不是多平台架构的应用：

所以，我们看看info.flags有没有设置这个标志，我们看到上面的pkg变量是通过解析apk文件的类PackageParser.java类中获取到的，所以可以去这个类中找这个标志位的设置。

这里看到了，如果在AndroidManifest.xml中设置了Application中的multiArch属性值的话就有，但是我们默认都没有设置这个属性值，那么就是false，也就是说一般应用都不是多平台的。所以上面的isMultiArch方法就返回false，代码就走到了这里：

在这里就有很多知识点了，而这里可以看到，就涉及到了so文件的释放工作了，主要是在NativeLibraryHelper类中，但是这里看到首先获取abiList值：

通过Build.SUPPORTED_ABIS来获取到的：

最终是通过获取系统属性：ro.product.cpu.abilist的值来得到的，我们可以使用getprop命令来查看这个属性值：

这里获取到的值是：arm64-v8a,armeabi-v7a,armeabi，我用的是64位的cpu设备，所以可以看到他有多个cpu架构可选，而且看到这个顺序会想到，这个顺序正好是向下兼容的顺序。

现在去看看NativeLibraryHelper类的copyNativeBinariesForSupportedAbi方法：

这个方法中主要干了三件事：

第一件事是获取应用所支持的arch架构类型

第二件事是通过架构类型获取so释放的目录

第三件事是native层中释放apk中的指定架构的so到设备目录中

第一件事：获取应用所支持的arch架构类型

NativeLibraryHelper类的findSupportedAbi方法，其实这个方法就是查找系统当前支持的架构型号索引值：

看看native方法的实现：

这里看到了，会先读取apk文件，然后遍历apk文件中的so文件，得到全路径然后在和传递进来的abiList进行比较，得到合适的索引值，其实实现逻辑很简单：abiList是：arm64-v8a,armeabi-v7a,armeabi，然后就开始比例apk中有没有这些架构平台的so文件，如果有，就直接返回abiList中的索引值即可，比如说apk中的libs结构如下：

那么这时候返回来的索引值就是0，代表的是arm64-v8a架构的。如果apk文件中没有arm64-v8a目录的话，那么就返回1，代表的是armeabi-v7a架构的。依次类推。得到应用支持的架构索引之后就可以获取so释放到设备中的目录了。

第二件事：获取so释放之后的目录

这里主要通过VMRuntime.java中的getInstructionSet方法：

这里调用了一个map结构值：

这里的arch架构和目录对应关系，如果arch是arm64-v8a的话，那么目录就是arm64了。

第三件事：释放apk中的so文件

直接调用的是native层方法iterateOverNativeFiles：

好了到这里就讲完了上面的三件事了，而这三件事做完之后，apk中的so文件就会被释放到本地设备中的指定目录中了，当然这里系统会根据abiList中的值以及apk中包含的arch类型的so来决定释放哪个目录中的so文件，比如这里通过ApplicationInfo类来打印当前应用的nativeLibraryDir值：

打印的结果：

看到了，因为是arm64-v8a类型的，所以目录是arm64的，而且可以看到这个应用不是多平台的。

我们可以看到Android中是如何释放apk中的so文件到本地目录的：

1、通过遍历apk文件中的so文件的全路径，然后和系统的abiList中的类型值进行比较，如果匹配到了就返回arch类型的索引值

2、得到了应用所支持的arch类型之后，就开始获取创建本地释放so的目录

3、然后开始释放so文件

我们在PackageMangerService类中继续往下看：

这里还要保存上面获取到应用支持的arch类型值，我们可以使用反射打印这个值：

打印结果：

这个值在后面应用创建VM的时候会用到。

接着开始设置应用的nativeLib路径了：

看看这个方法的实现：

这里先判断是不是64位：

通过arch类型对应的目录来判断的：

这里如果是64位，目录就是lib，如果是32位就是lib64：

这样就和我们上面释放so文件的目录保持一致了，所以这里的ApplicationInfo类中的lib路径就是我们上面释放so之后的路径了。

在之前说到了类加载器中的lib路径，我们可以打印一下库路径的，这里直接使用getClassLoader得到加载器打印即可：

这里看到Library的目录包含很多路径。

七、Android中64位系统如何兼容32位的so

上面分析完了，so文件的释放工作，下面继续来看一下如果一个64位系统的Android设备如何做到能够运行32位的so文件，这个就需要从应用的启动说起了，那么这个类就是ActivityManagerService.java，有一个核心的方法：startProcessLocked，这个方法就是向Zygote进程发送一个消息，为这个应用创建虚拟机开始运行程序了：

这里在发送消息给Zygote进程，看到这里通过ApplicationInfo中的primaryCpuAbi类型告诉Zygote改创建多少位的虚拟机，我们查看系统启动文件init.rc内容：

这里会启动一个64位的Zygote进程

然后启动一个32位的Zygot进程

所以这里应该就可以想明白了，原来系统启动的时候，如果是64位的系统设备，会启动两个Zygote进程用来兼容32位类型的应用，我们可以使用ps命令查看进程：

看到了，这里果然启动了两个Zygote进程，一个64位的，一个是32位的。所以兼容功能的大致流程图应该是这样的：

上层启动应用的时候会把应用的abi类型带过来，然后这里会根据这个类型发送给具体的Zygote进程消息，来创建虚拟机开始运行程序，这样就做到了兼容。

八、Android插件中如何加载so文件

有时候我们在开发插件的时候，可能会调用so文件，一般来说有两种方案：

一种是在加载插件的时候，先把插件中的so文件释放到本地目录，然后在把目录设置到DexClassLoader类加载器的nativeLib中。

一种在插件初始化的时候，释放插件中的so文件到本地目录，然后使用System.load方法去全路径加载so文件

这两种方式的区别在于，第一种方式的代码逻辑放在了宿主工程中，同时so文件可以放在插件的任意目录中，然后在解压插件文件找到这个so文件释放即可。第二种方式的代码逻辑是放在了插件中，同时so文件只能放在插件的assets目录中，然后通过把插件文件设置到程序的AssetManager中，最后通过访问assets中的so文件进行释放。

上面就全部分析完了Android中关于so加载的相关内容：

1、so编译平台问题

2、so加载流程分析

3、so文件释放功能分析

4、so文件兼容功能分析

5、插件中so文件调用功能分析

九、常见问题分析

第一个问题：Could not find libxxx.so

这个问题看上去很好理解，就是在调用加载so的方法的时候，到底层使用dlopen方法打开so文件，发现找不到这个so文件，那么这个问题产生的原因主要有两个：

第一个是我们的确忘了在工程的libs下存放so文件了；

第二个是我们把so文件放错目录了；

第一个原因就不多说了，主要来看第二原因：

有时候我们在开发项目的时候，可能会放多个架构类型的so文件，那么现在假如我的设备是arm64-v8a类型的，我的项目中有三个so文件，比如叫做AAA.so，BBB.so，CCC.so，然后我再arm64-v8a目录中放了AAA.so，BBB.so，而CCC.so忘了放了，但是会放到armeabi-v7a和armeabi目录中，那么这时候就会发生找不到CCC.so的错误，原因很简单：

上面分析了apk中so文件的释放逻辑，系统会先遍历apk中所有so文件的全路径，然后在结合abiList的值来决定最终释放哪个目录中的so文件，那么现在系统是arm64-v8a了，而apk中的libs下也有arm64-v8a，所以这里就会把apk中的libs\arm64-v8a中的所有so文件释放解压到本地目录中，而不会在去释放armeabi/armeabi-v7a了。因为arm64-v8a中没有CCC.so文件，所以最终释放到本地目录中也是没有这个so文件的，所以加载时找不到文件了。

解决办法：就是在使用so文件的时候，需要确定在每个架构类型目录中都要有相同的so文件即可。

第二个问题：32-bit instead of 64-bit

这个问题的原因主要是因为64位的Zygote进程创建的虚拟机中加载了32位的so文件，这个问题的产生原因主要有两个：

第一个是我们把不同架构类型的so文件放错目录了，比如armeabi/armeabi-v7a的so文件放到了arm64-v8a中了

第二个是我们在开发插件的过程中，宿主工程中有arm64-v8a目录，但是插件中加载so却是armeabi/armeabi-v7a类型的

第一个原因就不多说了，主要是因为so放错目录了，来看一下第二个原因，我们在开发插件的时候有时候需要在插件中去加载so文件，一般都是使用System.load方式去加载全路径的so文件，那么这里就可能存在一个问题，比如宿主工程中，放了所有架构的目录，包括了64位的，因为考虑插件的大小，所以在插件中只放了armeabi-v7a目录的so文件，如果设备是64位的系统，那么这时候插件加载so文件就会报错。原因就在于上面分析的so兼容问题中说到了，因为宿主工程中包含了64位的架构arm64-v8a类型，系统的abiList中也有arm64-v8a类型，所以这时候应用的ApplicationInfo的abi就是arm64-v8a了，那么就会发送消息给Zygote64的进程，创建的也是64位的虚拟机了，而最后插件中加载so的类型是32位的armeabi-v7a，那么就会报错了，因为32位的so文件不能运行在64位的虚拟机中的。

解决办法：宿主工程和插件工程中的so文件的架构类型保持一致，这个将会带来一个很大的问题，就是插件包会变得很大，因为宿主工程为了兼容多数机型，加入了多个类型的架构so文件，但是插件为了减小包大小，就放了指定类型的so文件，但是最终会存在这种问题，所以这个解决办法就要看项目需要了。

还有一个类似的问题：64-bit instead of 32-bit：

原理都是一样的，32位的虚拟机中加载了64位的so文件问题导致的。

第三个问题：Shared library already opened

这个问题在上面介绍so加载流程中已经介绍过了，原因主要是因为之前使用DexClassLoader加载so之后，so没有释放还在内存中，而在此启动有弄了一个新的DexClassLoader对象去加载so问题，就出错了。

我们使用DexClassLoader类去加载插件，但是因为我们为了插件能够实时更新，所以每次都会赋值新的DexClassLoader对象，但是第一次加载so文件到内存中了，这时候退出程序，但是没有真正意义上的退出，只是关闭了Activity了，这时候再次启动又会赋值新的加载器对象，那么原先so已经加载到内存中了，但是这时候是新的类加载器那么就报错了。

解决办法：

第一种方式：在退出程序的时候采用真正意义上的退出，比如调用System.exit(0)方法，这时候进程被杀了，加载到内存的so也就被释放了，那么下次赋值新的类加载就在此加载so到内存了。

第二种方式：就是全局定义一个static类型的类加载DexClassLoader也是可以的，因为static类型是保存在当前进程中，如果进程没有被杀就一直存在这个对象，下次进入程序的时候判断当前类加载器是否为null，如果不为null就不要赋值了，但是这个方法有一个弊端就是类加载器没有从新赋值，如果插件这时候更新了，但是还是使用之前的加载器，那么新插件将不会进行加载。

十、技术概要

本文主要介绍了Android中关于so的相关知识，主要包括so编译多架构问题，so加载流程问题，so释放问题，so系统兼容问题以及插件中加载so文件的功能解析，看完本文之后，我们需要了解到的知识点：

1、在NDK开发时，可以指定多种架构类型编译出多种类型的so文件。

2、so的加载流程主要是System类中的两个加载方法，最终都会调用Runtime中的nativeLoad的native方法，而这个native方法最终会调用dlopen来打开so文件，然后在调用dlsym方法调用so的JNI_OnLoad方法。

3、关于apk文件在安装的时候释放so文件到本地目录中，主要是结合当前设备的abiList信息(这个信息主要是通过系统属性：ro.product.cpu.abilist值来获取的)和apk中不同类型架构，来决定最终释放哪个类型目录中的so文件，释放完成之后，还需要设置应用的nativeLib路径，以及应用的abi信息，因为这个abi信息在后面启动虚拟机的时候需要用到。

4、因为现在有很多设备已经是64位系统了，但是为了兼容32位的so文件，所以这些64位系统就会在系统启动的时候创建两个Zygote进程，一个是64位的，一个是32位的，当一个应用启动的时候，需要创建虚拟机，那么这时候就会把应用的架构类型传递过去，系统会根据这个类型来交给哪个Zygote进程来处理这个应用启动事件。这样就可以做到so调用的兼容问题了。

5、插件中加载so文件现阶段主要有两种方式，一种是先释放插件中的so文件到本地目录，然后设置DexClassLoader的nativeLib路径；还有一种方式是先释放插件中的so文件，然后调用System.load来加载全局路径的so文件。

十一、问题总结

本文还总结了在使用so文件的时候，会遇到的一些问题，主要是三个问题：

1、so文件找不到问题

这个问题一般是因为我们忘记放了so文件，或者是so文件没有放置全部，也就是没有在libs目录中所有的架构类型目录中放置。

2、不同位数的虚拟机运行了不同位数的so文件

这个问题一般是因为我们在libs目录中把so文件放错目录了，或者是宿主工程和插件工程中的so文件架构类型目录没有保持一致。

3、类加载器加载so文件再次加载

这个问题一般是因为插件开发中使用了不同的DexClassLoader去加载多次相同的so文件导致的。

十二、知识延展

我们在开发的过程中有时候想知道系统的位数，那么这里网上告知说有好几种方法，其实那些都是忽悠人的，特别是在使用这个api的时候：android.os.Build.CPU_ABI，我就是在项目中被这个方法坑爹了，这个方法其实不是获取系统的位数，而是获取当前应用的架构类型位数，就是我们前面分析的ApplicationInfo中的abi信息，我们可以查看一下源码：

这里可以看到，这个字段已经被废弃了，因为他不靠谱呀，这个字段在Build类的static块中进行赋值的：

这里会通过VMRuntime类的is64Bit方法来判断当前虚拟机的位数，来获取这个值

这里还有两个系统属性：

ro.product.cpu.abilist32是32位的所有arch架构类型

ro.product.cpu.abilist64是64位的所有arch架构类型

而这两个字段值的合集就是前面的ro.product.cpu.abilist属性值。

而VMRuntime的is64Bit方法是native方法，实现如下：

看到了，这里得到的是虚拟机的位数，那么就是上面的Zygote进程的位数了。那么问题就来了，假如我的设备是64位的，但是我的项目中没有arm64-v8a类型的so文件，这时候在解析apk进行释放so文件的时候，就会得知架构类型是armeabi/armeabi-v7a了，因为遍历apk文件，没有找到arm64-v8a类型的so文件，这时候应用的abi类型就是armeabi/armeabi-v7a了，这就是32位的了，就会通知32位的Zygote进程创建了一个32位的虚拟机，那么此时我的项目中通过Build.CPU_ABI得到的系统位数就是32了，那么完全不是我们想要的了。

所以正确的获取系统位数的方法是：

Android5.0系统之后，可以通过ro.product.cpu.abilist属性字段值来判断，如果这个字段值中包含了64的话，那么就是64位系统了

Android5.0系统之前，需要通过ro.product.cpu.abi属性字段值来判断，不过5.0系统之前都是32位的，还没有出现64位呢。

十三、选择适当架构类型减小包大小

我们上面分析之后可以看到，如果想做到万无一失即，项目不报错，而且so运行效率也是非常高的话，就需要把那几个架构类型的so文件都要在项目中放一遍，那么这个问题就来了，如果so文件较大的话，apk包最终也是很大的，所以这里就需要做一次选择了。

1、我们在开发一个项目的时候因为，整个项目的so文件结构我们可以控制，所以为了防止apk包增大，我们可以考虑只放几个架构类型的so文件，比如最好的是放armeabi类型的，因为首先现在大部分设备采用cpu型号都是arm的，少数采用x86或者是mips类型的，其次是防止了armeabi类型之后，对于armeabi-v7a和arm64-v8a就可以兼容了，不会存在报错问题。但是因为系统需要兼容所以就会出现so运行效率的问题了，最好的效率就是指定架构类型的so运行在对应架构类型的设备中。因为现在大部分的设备系统版本都是4.0以上了，所以armeabi-v7a架构类型用的比较多了，所以有时候为了效率问题，项目中只放了这个架构类型的so文件，那么像老版本的手机armeabi的话就会报错了，当然这个错误是可以接受的即可。

2、有时候像x86和mips等少数类型架构的设备，开发程序的时候会单独出一个版本比如叫做xxx应用x86版本

3、在开发SDK的时候，因为开发之后的SDK包是给其他app接入的，而对于接入的app，我们不能做太多的限制，所以理论上应该把所有架构类型的so都要提供，这样给需要接入的app进行选择即可，比如像百度地图SDK：

十四、总结

本文主要是介绍了Android中关于so的相关知识，而这些知识点都是在使用so文件中会经常用到的，同时一些问题也是我们会遇到的，这里只是做了一个总结，同时也给出了插件中加载so文件的方案已经遇到的问题解决思路等内容。

更多内容：点击这里

关注微信公众号，最新Android技术实时推送