HDC调试需求开发（15万预算）,能者速来！>>>
正式开始这个话题之前，先简单介绍一下什么是NDK和JNI，部分内容来自网络
Android NDK 是什么，为什么我们要用 NDK ？ Android NDK 是在 SDK 前面又加上了“原生”二字，即 Native Development Kit ，因此又被 Google 称为“ NDK ”。众所周知， Android 程序运行在 Dalvik 虚拟机中， NDK 允许用户使用类似 C / C++ 之类的原生代码语言执行部分程序。NDK包括了： 从 C / C++ 生成原生代码库所需要的工具和 build files 。 将一致的原生库嵌入可以在 Android 设备上部署的应用程序包文件（ application packages files ，即 .apk 文件）中。 支持所有未来 Android 平台的一些列原生系统头文件和库
为何要用到 NDK ？概括来说主要分为以下几种情况： 代码的保护，由于 apk 的 java 层代码很容易被反编译，而 C/C++ 库反汇难度较大。 在 NDK 中调用第三方 C/C++ 库，因为大部分的开源库都是用 C/C++ 代码编写的。 便于移植，用 C/C++ 写的库可以方便在其他的嵌入式平台上再次使用。
Android JNI 是什么？和 NDK 是什么关系？ Java Native Interface(JNI) 标准是 java 平台的一部分，它允许 Java 代码和其他语言写的代码进行交互。 JNI 是本地编程接口，它使得在 Java 虚拟机 (VM) 内部运行的 Java 代码能够与用其它编程语言 ( 如 C 、 C++ 和汇编语言 ) 编写的应用程序和库进行交互操作。
简单来说，可以认为 NDK 就是能够方便快捷开发 .so 文件的工具。 JNI 的过程比较复杂，生成 .so 需要大量操作，而 NDK 就是简化了这个过程。 NDK 的异常会不会导致程序 Crash ， NDK 的常见的有哪些类型异常？
NDK 编译生成的 . so 文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于 Java 代码异常造成的程序崩溃，在 NDK 的异常发生时，程序在 Android 设备上都会立即退出，即通常所说的闪退，而不会弹出“程序 xxx 无响应，是否立即关闭”之类的提示框。
NDK 是使用 C/C++ 来进行开发的，熟悉 C/C++ 的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（ NULL ）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生一个无效地址错误。常见的错误类型如下： 初始化错误 访问错误 数组索引访问越界 指针对象访问越界 访问空指针对象 访问无效指针对象 迭代器访问越界 内存泄露 参数错误 堆栈溢出 类型转换错误 数字除 0 错误 NDK错误发生时，我们能拿到什么信息？
利用 Android NDK 开发本地应用的时候，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在 logcat 中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“ Android NDK 崩溃”，可以搜索到很多文章来介绍如何通过 Android 提供的工具来查找和定位 NDK 的错误，但大都晦涩难懂。下面以一个实际的例子来说明，首先生成一个错误，然后演示如何通过两种不同的方法，来定位错误的函数名和代码行。
首先，看我们在 hello-jni 程序的代码中做了什么（有关如何创建或导入工程，此处略），看下图：在 JNI_OnLoad() 的函数中，即 so 加载时，调用 willCrash() 函数，而在 willCrash() 函数中， std::string 的这种赋值方法会产生一个空指针错误。这样，在 hello-jni 程序加载时就会闪退。我们记一下这两个行数：在 61 行调用了 willCrash() 函数；在 69 行发生了崩溃。

下面来看看发生崩溃（闪退）时系统打印的 logcat 日志： [plain] view plain copy *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys' pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 r0 00000000 r1 beb123a8 r2 80808080 r3 00000000 r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44 r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010 backtrace: #00 pc 00023438 /system/lib/libc.so #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so #05 pc 000505b9 /system/lib/libdvm.so #06 pc 00068005 /system/lib/libdvm.so #07 pc 000278a0 /system/lib/libdvm.so #08 pc 0002b7fc /system/lib/libdvm.so #09 pc 00060fe1 /system/lib/libdvm.so #10 pc 0006100b /system/lib/libdvm.so #11 pc 0006c6eb /system/lib/libdvm.so #12 pc 00067a1f /system/lib/libdvm.so #13 pc 000278a0 /system/lib/libdvm.so #14 pc 0002b7fc /system/lib/libdvm.so #15 pc 00061307 /system/lib/libdvm.so #16 pc 0006912d /system/lib/libdvm.so #17 pc 000278a0 /system/lib/libdvm.so #18 pc 0002b7fc /system/lib/libdvm.so #19 pc 00060fe1 /system/lib/libdvm.so #20 pc 00049ff9 /system/lib/libdvm.so #21 pc 0004d419 /system/lib/libandroid_runtime.so #22 pc 0004e1bd /system/lib/libandroid_runtime.so #23 pc 00001d37 /system/bin/app_process #24 pc 0001bd98 /system/lib/libc.so #25 pc 00001904 /system/bin/app_process stack: beb12340 012153f8 beb12344 00054290 beb12348 00000035 beb1234c beb123c0 [stack] ……

如果你看过 logcat 打印的 NDK 错误时的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的 Android 开发者，在面对 NDK 日志时也大都默默的选择了无视。
“符号化”NDK错误信息的方法 其实，只要你细心的查看，再配合 Google 提供的工具，完全可以快速的准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对 NDK 错误进行符号化的工作，需要保留编译过程中产生的包含符号表的 so 文件，这些文件一般保存在 $PROJECT_PATH/obj/local/ 目录下。 第一种方法： ndk-stack
这个命令行工具包含在 NDK 工具的安装目录，和 ndk-build 和其他一些常用的 NDK 命令放在一起，比如在我的电脑上，其位置是 /android-ndk-r9d/ndk-stack 。根据 Google 官方文档， NDK 从 r6 版本开始提供 ndk-stack 命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用 ndk –stack 命令也有两种方式 使用ndk-stack实时分析日志
在运行程序的同时，使用 adb 获取 logcat 日志，并通过管道符输出给 ndk-stack ，同时需要指定包含符号表的 so 文件位置；如果你的程序包含了多种 CPU 架构，在这里需求根据错误发生时的手机 CPU 类型，选择不同的 CPU 架构目录，如： [plain] view plain copy adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

当崩溃发生时，会得到如下的信息： [plain] view plain copy ********** Crash dump: ********** Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys' pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 Stack frame #00 pc 00023438 /system/lib/libc.so (strlen+72) Stack frame #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traits<char>::length(char const*)+20): Routine std::char_traits<char>::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229 Stack frame #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639 Stack frame #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69 Stack frame #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61 Stack frame #05 pc 000505b9 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516) Stack frame #06 pc 00068005 /system/lib/libdvm.so Stack frame #07 pc 000278a0 /system/lib/libdvm.so Stack frame #08 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180) Stack frame #09 pc 00060fe1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272) ……（后面略）
我们重点看一下 #03 和 #04 ，这两行都是在我们自己生成的 libhello-jni.so 中的报错信息，那么会发现如下关键信息： [plain] view plain copy #03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69 #04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61

回想一下我们的代码，在 JNI_OnLoad() 函数中（第 61 行），我们调用了 willCrash() 函数；在 willCrash() 函数中（第 69 行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？ 先获取日志，再使用ndk-stack分析
这种方法其实和上面的方法没有什么大的区别，仅仅是 logcat 日志获取的方式不同。可以在程序运行的过程中将 logcat 日志保存到一个文件，甚至可以在崩溃发生时，快速的将 logcat 日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。 [plain] view plain copy adb shell logcat > 1.log ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –dump 1.log 第二种方法：使用addr2line和objdump命令
这个方法适用于那些，不满足于上述 ndk-stack 的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示 ndk-stack 命令的工作原理是什么，尽管用起来稍微麻烦一点，但是可以满足一下程序员的好奇心。
先简单说一下这两个命令，在绝大部分的 linux 发行版本中都能找到他们，如果你的操作系统是 linux ，而你测试手机使用的是 Intel x86 系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是 Windows ，而手机很有可能是 armeabi 系列。
别急，在 NDK 中自带了适用于各个操作系统和 CPU 架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在 NDK 目录的 toolchains 目录下找到他们。以我的 Mac 电脑为例，如果我要找的是适用于 armeabi 架构的工具，那么他们分别为 arm-linux-androideabi-addr2line 和 arm-linux-androideabi-objdump ；位置在下面目录中，后续介绍中将省略此位置： [plain] view plain copy /Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/
假设你的电脑是 windows ， CPU 架构为 mips ，那么你要的工具可能包含在这个目录中： [plain] view plain copy D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\


好了言归正传，如何使用这两个工具，下面具体介绍： 1. 找到日志中的关键函数指针
其实很简单，就是找到 backtrace 信息中，属于我们自己的 so 文件报错的行。
首先要找到 backtrace 信息，有的手机会明确打印一行 backtrace （比如我们这次使用的手机），那么这一行下面的一系列以“ # 两位数字 pc ”开头的行就是 backtrace 信息了。有时可能有的手机并不会打印一行 backtrace ，那么只要找到一段以“ # 两位数字 pc ”开头的行，就可以了。

其次要找到属于自己的 so 文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址

2. 使用 addr2line 查找代码位置 执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可 [plain] view plain copy arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58
结果如下 [plain] view plain copy /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229 /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639 /WordSpaces/hello-jni/jni/hello-jni.cpp:69 /WordSpaces hello-jni/jni/hello-jni.cpp:6

从 addr2line 的结果就能看到，我们拿到了我们自己的错误代码的调用关系和行数，在 hello-jni.cpp 的 69 行和 61 行（另外两行因为使用的是标准函数，可以忽略掉），结果和 ndk-stack 是一致的，说明 ndk-stack 也是通过 addr2line 来获取代码位置的。
3. 使用 objdump 获取函数信息
通过 addr2line 命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，显得不那么“完美”，对于追求极致的程序员来说，这当然是不够的。下面我们就演示怎么来定位函数信息。


使用如下命令导出函数表： [plain] view plain copy arm-linux-androideabi-objdump –S obj/local/armeabi/libhello-jni.so > hello.asm


在生成的 asm 文件中查找刚刚我们定位的两个关键指针 00004fb4 和 00004f58





从这两张图可以清楚的看到（要注意的是，在不同的 NDK 版本和不同的操作系统中， asm 文件的格式不是完全相同，但都大同小异，请大家仔细比对），这两个指针分别属于 willCrash() 和 JNI_OnLoad() 函数，再结合刚才 addr2line 的结果，那么这两个地址分别对应的信息就是： [plain] view plain copy 00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jni.cpp:69 00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jni.cpp:61

相当完美，和 ndk-stack 得到的信息完全一致！

使用Testin崩溃分析服务定位NDK错误 以上提到的方法，只适合在开发测试期间，如果你的应用或者游戏已经发布上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题，几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。
目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入 SDK ，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，处于领先地位的是国内的 Testin 和国外的 crittercism ，其中 crittercism 需要付费，而且没有专门的中国开发者支持，我们更推荐 Testin ，其崩溃分析服务是完全免费的。
Testin 从 1.4 版本开始支持 NDK 的崩溃分析，其最新版本已经升级到 1.7 。当程序发生 NDK 错误时，其内嵌的 SDK 会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过 logcat 日志获取到的函数指针）、设备信息、线程信息等等， SDK 将这些信息上报至 Testin 云服务平台，只要登陆到Testin平台，就可以看到所有用户上报的崩溃信息，包括NDK；并且这些崩溃做过归一化的处理，在不同系统和ROM的版本上打印的信息会略有不同，但是在Testin的网站上这些都做了很好的处理，避免了我们一些重复劳动。



上图的红框部分，就是从用户手机上报的，我们自己的so中报错的函数指针地址堆栈信息，就和我们开发时从 logcat 读到的日志一样，是一些晦涩难懂的指针地址， Testin 为 NDK 崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的 so 文件上传（上文我们提到过的 obj/local/ 目录下的适用于各个 CPU 架构的 so ），就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。
而且使用这个功能还有一个好处：这些包含符号表的 so 文件，在每次我们自己编译之后都会改变，很有可能我们刚刚发布一个新版本，这些目录下的so就已经变了，因为开发者会程序的修改程序；在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。所以我们在编译打包完成后记得备份我们的so文件。这时我们可以将这些文件上传到 Testin 进行符号化的工作， Testin 会为我们保存和管理不同版本的 so 文件，确保信息不会丢失。来看一下符号化之后的显示：