如何定位Android NDK开发中遇到的错误
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日志时也大都默默的选择了无视。
如何定位Android NDK开发中遇到的错误
NDK编译生成的.so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（NULL）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生一个无效地址错误。常见的错误类型如下：初始化错误访问错误 数组索引访问越界指针对象访问越界访问空指针对象访问无效指针对象迭代器访问越界内存泄露参数错误堆栈溢出类型转换错误数字除0错误利用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::length(char const*)+20): Routine std::char_traits::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, std::allocator >::basic_string(char const*, std::allocator 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\
如何在Ubuntu下搭建Android NDK开发环境
1 搭建Android SDK开发环境2 下载NDK开发包3打开官网： 下载NDK 开发包，当前最新版本是r7b下载解压到 ~/bin 目录下，3 配置NDK环境参数打开 ~/.bashrc文件:在文件最后一行添加一行如下指令：4保存关闭.这样配置后，以后就可以很方便地使用NDK包中所包含的工具了。接下来测试一下.打开终端输入如下指令:如果出现如下显示，就表示可以了.
