首先，每天看到不断有新人关注着这个公众号，心情很是愉悦。一种认可，一种信任，也是我前进的动力。感谢大家的支持与鼓励。

本文讲解内容有

loadLibrary流程

linker

ELF

ndk开发以及配置调试版本

ndk-gdb --start调试so

gdb 调试bin文件

　gdb调试android apk方案

关于本文讲解使用的代码，都在网盘提供了，可以自行下载。

(链接: https://pan.baidu.com/s/1hrIxJdq 密码: jfwz)

00

开发android 应用，主要围绕着java语言，可是，如果我们需要追求性能，或者需要调用之前我们已经写好的c c so库的时候，或者和硬件打交道的时候，那么我们就会接触到JNI（java native inte**ce）。

我们知道，java是在其虚拟机里面运行。我们简单举个例子吧。我让你使用任何一个语言，写一段代码：打开一个文件，读取每一行，如果这一行内容是1，我们就在窗口显示生活真美好。 想一下，是否都能写出来？

这里举的例子，简单的解释了虚拟机的动作，打开一个文件（输入），读取每一行（内容），如果这一行内容是1（解析），我们就在窗口显示生活真美好（输出），比起这个来说，java虚拟机比这个复杂，但是基础核心的原理就是这个了。

我们本节去讲一个内容，System.loadLibrary（**X） 的执行过程。此过程完成将so库加载进来，打通java和c c 本地库的桥梁，实现相互调用。（此文牵扯概念 javaVM JNI ELF 动态库静态库）

我们要做JNI，少不了使用

嗯，我们这节，就是展看loadLibrary，来看这个方法都做了哪些事情。

我们这里看下参数：libname 将加载的库名字，比如我们库为libtest_jni.so 这里则写为test_jni,其余的系统会帮我们拼接。

继续向下看，发现调用了Runtime类里面的loadLibrary0方法，我们看下：

我们看到有两个参数：第一个为Classloader，这个为我们的类加载器，我们这里的参数为VMStack.getCallingClassLoader()，于是我们看下这段代码。

看到这里为native，于是它本身是使用c或者c 本地语言编写的了，我们找下位置。通过搜索getCallingClassLoader，我们找到了本地实现的地方在dalvik_system_VMStack.cc里面，于是我们截图，来看下。

这里NATIVE_METHOD是个宏定义

于是

会转化为

这个就是jni编写中，需要配置的对应表，主要完成java和c语言函数对应，参数和返回值对应的关系，给了这些，虚拟机才会在java和c之间建立起来关系，知道哪个java函数调用的真正正确的c语言函数，同时c也是可以反向调用java的，更多可以百度jni的编写。

关于getCallingClassLoader这个是如何加入到系统的，就是上面的register_dalvik_system_VMStack方法了。

我们不对这里展开了，此方法是在runtime.cc的InitNativeMethods方法里面的RegisterRuntimeNativeMethods完成。有兴趣的可以去看看。我们继续跟踪system.loadLibrary，这里继续看VMStack.getCallingClassLoader()。

01

通过上面的展看，我们知道了这个对应的c方法为：VMStack_getCallingClassLoader，于是我们看到：

这里因为不熟悉，就不讲了。

loadLibrary0 里面主要调用的方法为：

loader.findLibrary(libraryName); 去查找是否存在此动态库，没有就报找不到异常。

然后我们调用doLoad去加载。

doLoad主要完成，传入设置的librarySearchPath，然后调用本地代码nativeLoad方法。搜索nativeLoad，我们找到了它对应的实现，在Runtime.c

里面

根据之前展开的方式，此函数为：Runtime_nativeLoad，于是我们看到：

在OpenjdkJvm.cc里面：

关键方法，通过拿到当前的虚拟机vm，调用对应的LoadNativeLibrary（java_vm_ext.cc）方法，去真正加载对应的so。

我们来到java_vm_ext.cc里面，去看下LoadNativeLibrary真正的执行过程：

这里我们关系的是高亮的几个函数：OpenNativeLibrary，完成加载so的过程。

FindSymbol("JNI_OnLoad"）完成找出so里面的JNI_OnLoad方法，如果有，使用(*jni_on_load)(this, nullptr)调用，返回so使用的java版本。这个JNI_OnLoad就是我们加载so的时候，会主动触发的一个初始化方法了。在这里主要完成java和c的对应关系方法，然后使用RegisterNativeMethods将此关系注册进入vm，以便后续调用能够找到。

扩展：

用于Android ART虚拟机JNI调用的NativeBridge介绍，地址为：

http://www.aichengxu.com/android/1473706.htm

02

我们停一下，完成一个简单的测试demo代码，以便我们调试使用。

参考http://blog.csdn.net/a332324956/article/details/8703286 来写一个JNI
搭配着eclipse去编译出来一个libtest_jni.so。(后续此工程会直接提供下载)

工程目录为：这里jni就是需要编出来so的地方。我们右键jnidemo选择properties，然后选择下Builders，点击new，创建一个编译规则。

编写一个调试：

这里Location指的是ndk-build脚本位置
Working Directory 指的是当前项目的src/jni,我们要使用ndk-build将jni目录下的android.mk执行，完成生成so的动作。

最后生成出来libtest_jni.so
我们在java工程使用下。（我们要在此基础上进行调试，所以我们使用的是自己load，不是写在static语句里面）

完整代码，文章最后提供，可以看着代码然后阅读。

我们在loadLibrary0上面打断点，然后看下流程：

我们可以看到看到，这里的loader为PathClassLoader.java，所以此处的findLibrary就是PathClassLoader.java文件里面的了。然后发现PathClassLoader继承自 BaseDexClassLoader，于是我们关心BaseDexClassLoader代码。

此段代码，完成在此app的本地so库的搜索路径下，查找我们的test_jni动态库，找到后path返回此so的绝对路径，以使后面的dlopen去动态打开此库。在此处，libname就是/data/app/com.example.jnidemo-2/lib/arm/libtest_jni.so，这个就是我们的jni动态库真正的位置了。

关于动态库dlopen dlsym 的用法，参照http://blog.csdn.net/edonlii/article/details/8445239 主要就是打开so，然后找到对应函数，然后执行。

按照这个文档，去调试so（需要下载android的ndk）

http://blog.csdn.net/kaiqiangzhang001/article/details/21108857

打上断点的截图为：

我们这里提供一个Android的加载/链接器linker的讲解

http://blog.csdn.net/dinuliang/article/details/5509009

关于android linker的代码位置bionic/linker，可以去阅读。

03

我们回到之前的讲解，来找下LoadNativeLibrary调用的OpenNativeLibrary方法。在native_loader.cpp文件内找到此文件。

这里android调用了android_dlopen_ext方法，来实现动态库的加载，返回dlextinfo，而非android的，则是调用dlopen加载的。

我们搜索android_dlopen_ext，发现在/bionic/libdl/里面的/bionic/libdl/libdl.c里面有

看，是个空方法，没有实际动作，看到这里的注释，意思是我们的dynamic linker 实现了这个方法，我们找到linker（手机里面的/system/bin/linker），我们在linker的源码里面dlfcn.cpp找到android_dlopen_ext

但是在最终编译出来的linker里面是被修改成了__dl_android_dlopen_ext

找到linker文件里面的方法，具体的操作是：

将linker提取出来

然后运行，导出来内容

然后看到了__dl_android_dlopen_ext方法的实现体：

关于linker的启动，可以参考http://www.myexception.cn/android/1930690.html 阅读。同时adnroid源码也是提供了一个简单解释：

在/development/ndk/platforms/下面的README.CRT.TXT文件，有如下内容：

完整的我提交网盘了，可以去下载阅读。

04

在bionic/linker里面的Android.mk文件，发现了一段注释，可以解释__dl_android_dlopen_ext和android_dlopen_ext 怎么变化的。

这里的--prefix-symbols=__dl_ 就是给名字的符号上面加入一个前缀，于是我们的android_dlopen_ext 就变成了__dl_android_dlopen_ext。想找到编译linker的所有编译规则，参数，去mmm bionic/linker，就会在out下面生成一个-mmm-._bionic_linker_Android.mk.ninja文件，这个就是我们生成linker的所有规则，从里面去找--prefix-symbols，能看到

生成linker的时候，使用了objcopy修改了方法名。

我们调试linker的代码，我们因为加载的是__dl_android_dlopen_ext ,于是我们gdb下断点 b__dl_android_dlopen_ext ,这样子我们打断点，运行时候会在加载动态库时候，停下来：

可以看到，断点成功。

info sharedlibrary 查看当前需要的so。

info breakpoints 查看断点信息

bt 查看堆栈

b 方法 下断点

delete num 删除对应断点。

file **.so (有调试信息的库，然后我们调试，就会变成有效信息)

05

关于gdb的使用，可以参考

http://blog.csdn.net/ghostyu/article/details/8083228

关于solib-absolute-prefix 和solib-search-path的区别 ,可以参考：

http://blog.csdn.net/caspiansea/article/details/16798735

我们这里看到了一个地址信息，又没有显示出来，这里为0xaafceefa，我们想找到这个地址，对应的代码，该如何找呢？

adb shell

ps | grep demo (这里demo是我们包名)

我们关心的是10171（进程id），然后我们查找/proc/10171/maps

cat/proc/10171/maps ，找到aafc是在这个位置：

aada1000-ab1f4000 r-xp 00000000 103:08 1377 /system/lib/libart.so

于是我们file加载下这个libart.so

然后重新调试，看效果：

看#2，是不是出来了。

我们打断点，发现b android_dlopen_ext 和 b __dl_android_dlopen_ext 是一个位置（bionic/linker/dlfcn.cppline 82）.所以我们实际的android_dlopen_ext就是__dl_android_dlopen_ext，也就是dlfcn.cpp文件内容了。

我们将bionic放置到我们调试的ndk-gdb --start目录，再次调试，代码就检索出来了。

漫漫长路，我们又可以启程了，我们当前需要阅读的代码，就围绕着android_dlopen_ext（dlfcn.cpp）函数开展了。先开心看一个内容，这里我将编译出来的所有so加载进来了，我们看到调试栈就会变成：

看到没，调用信息一目了然。

我们看下追踪这条代码线，可以找到我们的调用关系：

android::OpenNativeLibrary --