如何定位Android NDK开发中遇到的错误

Question

如题所述

Answer 1

　　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打印的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文件，确保信息不会丢失。