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

时间 2019-12-02

原文原文链接

应部分同窗要求，把以前的几篇文章合成这个一篇java

正式开始这个话题以前，先简单介绍一下什么是NDK和JNI，部份内容来自网络linux

Android NDK是什么，为何咱们要用NDK？

Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，所以又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK容许用户使用相似C / C++之类的原生代码语言执行部分程序。NDK包括了：android

从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++和汇编语言)编写的应用程序和库进行交互操做。shell

简单来讲，能够认为NDK就是可以方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so须要大量操做，而NDK就是简化了这个过程。编程

NDK的异常会不会致使程序Crash，NDK的常见的有哪些类型异常？

NDK编译生成的.so文件做为程序的一部分，在运行发生异常时一样会形成程序崩溃。不一样于Java代码异常形成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会当即退出，即一般所说的闪退，而不会弹出“程序xxx无响应，是否当即关闭”之类的提示框。windows

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::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\

好了言归正传，如何使用这两个工具，下面具体介绍：

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文件，确保信息不会丢失。来看一下符号化以后的显示：