Android NativeCrash 捕获与解析

NE全称 NativeException，就是C或者C++运行过程中产生的错误，NE不同于普通的 Java 错误，普通的logcat无法直接还原成可阅读的堆栈，一般没有源码也无法调试。

所以日常应用层的工程师，即使我们内部有云诊断的日志，一般也会忽略NE的错误，那么遇到这些问题，作为应用层、对C++不甚了解的工程师能否解决还原堆栈，能否快速定位或者解决NE的问题呢？

下面将着重介绍：

1.1 so 组成

---

我们先了解一下 so 的组成，一个完整的 so 由C代码加一些 debug 信息组成，这些debug信息会记录 so 中所有方法的对照表，就是方法名和其偏移地址的对应表，也叫做符号表，这种 so  也叫做未 strip 的，通常体积会比较大。

通常release的 so 都是需要经过一个strip操作的，这样strip之后的 so 中的debug信息会被剥离，整个 so 的体积也会缩小。

如下图所示：

如下可以看到strip之前和之后的大小对比。

如果对 NE 或者 so 不了解的，可以简单将这个debug信息理解为Java代码混淆中的mapping文件，只有拥有这个mapping文件才能进行堆栈分析。

如果堆栈信息丢了，基本上堆栈无法还原，问题也无法解决。

所以，这些debug信息尤为重要，是我们分析NE问题的关键信息，那么我们在编译 so 时候务必保留一份未被strip的so 或者剥离后的符号表信息，以供后面问题分析，并且每次编译的so 都需要保存，一旦产生代码修改重新编译，那么修改前后的符号表信息会无法对应，也无法进行分析。

1.2 查看 so 状态

---

事实上，也可以通过命令行来查看 so 的状态，Mac下使用 file 命令即可，在命令返回值里面可以查看到so的一些基本信息。

如下图所示，stripped代表是没有debug信息的so，with debug_info, not stripped代表携带debug信息的so。

file libbreakpad-core-s.so

libbreakpad-core-s.so: *******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, stripped

file libbreakpad-core.so

libbreakpad-core.so: ******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, with debug_info, not stripped

如果你是 Windows系统的话，那么我劝你装一个 Linux子系统，然后在 Linux执行同样的命令，同样也可以得到该信息。

接下来看下我们如何获取两种状态下的so。

1.3 获取 strip 和未被 strip 的 so

---

目前Android Studio无论是使用mk或者Cmake编译的方式都会同时输出strip和未strip的so，如下图是Cmake编译so产生的两个对应的so。

strip之前的so路径：build/intermediates/transforms/mergeJniLibs

strip之后的so路径：build/intermediates/transforms/stripDebugSymbol

另外也可以通过Android SDK提供的工具aarch64-linux-android-strip手动进行strip，aarch64-linux-android-strip这个工具位于/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains目录下。

这个工具有多种版本，主要针对不同的手机CPU架构，如果不知道手机的CPU架构，可以连接手机使用以下命令查