Androids中的System.loadLibrary对于依赖so的加载分析

        Android虽然基于Linux系统，但Android本身做了大量的修改。其中对于系统C库更是自己重新实现——Bionic库。在源码目录结构中bionic可以找到相关内容。话题好像偏离有点远，但System.loadLibrary最终还是调用到bionic库中的函数dlopen。这个dlopen搜索依赖so的路径与Linux本身有着不一样的实现，并且在4.2.2版本及以下有着无法隐式加载app目录下依赖so的缺陷，直到4.3才被修复。

        关于System.loadLibrary和System.load两个在java中加载so的方法，已经有人进行个大致的分析（Java中System.loadLibrary() 的执行过程  文章中的分析内容是4.2.2版本，仍然不支持隐式加载app目录下依赖so），可以先看看这篇文章里关于以上两个java函数的实现，了解大部分的流程。然后，这里就要开始从dlopen开始分析，对于依赖so加载的问题。

具体分析

        首先来看这样一个例子，有两个so，liba.so、libb.so。其中，liba.so引用了libb.so导出的符号，并且是直接引用符号，也就是

需要加载器在运行时的动态隐式链接。在加载liba.so的时候，Java层里，我们会调用System.loadLibrary()，或者System.load()来

指定so的路径，然后最终会调用到native代码中，使用dlopen加载liba.so，就会根据liba.so的Dynamic section中列出类型为

DT_NEEDED的依赖共享库so，并且会递归地一个一个地加载依赖so。在LInux下，加载这些依赖so的路径会是 1. 环境变量LD_LIBRARY指明的路径。