接着上篇“Android系统加载native库的流程和原理分析（上）” ，我们讲完native的加载流程。
system.java中，loadLibrary函数就是我们直接在java中经常调用的函数，就是这个：
public static void loadLibrary(String libname) {
Runtime.getRuntime().loadLibrary0(Reflection.getCallerClass(), libname);
}
然后调用到了runtime.java中：
void loadLibrary0(ClassLoader loader, String libname) {
loadLibrary0(loader, null, libname);
}
我们注意到system.java中的传入的classLoader是通过反射来获取的Reflection.getCallerClass()，通过这个方法来获取的好处，可以知道当前APP运行的是32bit还是64bit的，后面我们跟踪debug也能发现，整个安卓这种会有classLoader两个对象，一个64位专门负责加载64位的jar或者库，而32位的专门用于加载32位的jar或者库。
回到我们追溯的librarySearchPath，我们去BaseDexClassLoader.java代码中去找，librarySearchPath也是别人传来的，那么到底是谁传进来的呢？
仔细查看 BaseDexClassLoader是继承自ClassLoader
public class BaseDexClassLoader extends ClassLoader
进入到ClassLoader.java中我们可以看到它是通过createSystemClassLoader来创建对应的loader
最后提两点疑问，有兴趣的可以去研究一下：）
1、LoadNativeLibrary中的线程使用的是Thread* self = Thread::Current() ，为何不直接用this？
2、LoadNativeLibrary 是通过什么方法来判断这个库已经加载到虚拟机了呢？
