"
Android 开发中，NE一直是不可忽略却又异常难解的一个问题，原因是这里面涉及到了跨端开发和分析，需要同时熟悉 Java，C&C++，并且需要熟悉 NDK开发，并且解决起来不像 Java异常那么明了，本文为了解决部分疑惑，将从NE的捕获，解析与还原等三个方面进行探索。
一、NE 简介
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。
?1234file libbreakpad-core-s.solibbreakpad-core-s.so: *, BuildID【sha1】=54ad86d708f4dc0926ad220b098d2a9e71da235a, strippedfile libbreakpad-core.solibbreakpad-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架构，可以连接手机使用以下命令查看：
?12adb shell cat /proc/cpuinfoProcessor : AArch64 Processor rev 12 (aarch64)
如上图可以看到我的手机CPU用的是aarch64，所以使用aarch64对应的工具aarch64-linux-android-strip，由于NDK提供了很多工具，后续都依照此原则使用即可：
?1234aarch64架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-striparm架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-strip
使用如下命令可以直接将debug的so进行strip
?1aarch64-linux-android-strip --strip-all libbreakpad-core.so
使用Cmake进行编译的时候，可以增加如下命令，可以直接编译出strip的so
?12#set(CMAKE_C_FLAGS_RELEASE ""${CMAKE_C_FLAGS_RELEASE} -s"")#set(CMAKE_CXX_FLAGS_RELEASE ""${CMAKE_CXX_FLAGS_RELEASE} -s"")
使用mk文件进行编译的时候，可以增加如下命令，也可以直接编译出strip的so
?1-fvisibility=hidden
二、NE 捕获与解析
NE解析顾名思议就是堆栈解析，当然所有的前提就是需要保存一份带符号表、也就是未被strip的so，如果你只有strip之后的so，那就无能为力了，堆栈基本无法还原了。
一般有以下三种方式可以捕获和还原堆栈。
2.1 logcat捕获
顾名思义，就是通过logcat进行捕获，我们通过Android Studio打开logcat，制造一个NE，只能看到很多类似#00 pc 00000000000161a0的符号，并没有一个可以直接阅读的日志，我们想通过logcat直接输出一份可以直接阅读的log。
可以使用Android/SDK/NDK下面提供的一个工具ndk-stack，它可以直接将NE输出的log解析为可阅读的日志。
ndk-stack一般是位于ndk的工具下面，Mac下的地址为
?1/Users/XXXX/Library/Android/sdk/ndk/21.3.6528147/ndk-stack
然后在该目录下执行控制台命令，或者在 Android Studio的terminal中执行也可
?1adb shell logcat | androidsdk绝对路径/ndk-stack -sym so所在目录
如此控制台在应用发生NE的时候便会输出如下日志，由日志可以看出，崩溃对应的so以及对应的方法名，如果有c的源码，那么就很容易定位问题。
?123456promote:~ njvivo$ adb shell logcat | ndk-stack -sym libbreakpad-core.so** Crash dump: **Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'#00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)#01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)Crash dump is completed
其实ndk-stack这个工具原理就是内部集成利用了addr2line来实时解析堆栈并且显示在控制台中。
看到这里有的小伙伴就觉得那这个不是很简单，但是实际的崩溃场景一是不容易复现，二是用户的场景有时候很难模拟，那么线上的NE崩溃又该如何监测和定位呢，有两种方式。
2.2 通过DropBox日志解析--适用于系统应用
这个很简单，DropBox会记录JE，NE，ANR的各种日志，只需要将DropBox下面的日志传上来即可进行分析解决，下面贴上一份日志示例。
解析方案1：
借助上述的ndk-stack工具，可以直接将DropBox下面的日志解析成堆栈，从中可以看出，崩溃在breakpad.cpp第111行的Crash()方法中。
?12345678910ndk-stack -sym /Users/njvivo/Desktop/NE -dump data_app_native_crash@1605531663898.txt** Crash dump: **Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'#00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)Crash()/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111:8Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:122:0#01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)Crash dump is completed
解析方案2：
还是利用Android/SDK/NDK提供的工具linux-android-addr2line，这个工具位于/Users/njvivo/Library/Android/sdk/ndk目录下，有两个版本。
?1234aarch64架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-addr2linearm架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line
命令使用方法如下，结合未被strip的so以及日志里面出现的堆栈符号00000000000161a0，同样可以解析出崩溃地址和方法。
?1234aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 00000000000161a0 Crash()/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111
基于以上，看似也很简单，但是有一个致命的问题就是DropBox只有系统应用能访问，非系统应用根本拿不到日志，那么，非系统应用该怎么办呢？
2.3 通过BreakPad捕获解析--适用于所有应用
非系统应用可以通过google提供的开源工具BreakPad进行监测分析，CrashSDK也是采用的此种方式，可以实时监听到NE的发生，并且记录相关的文件， 从而可以将崩溃和相应的应用崩溃时的启动、场景等结合起来上报。
下面简单介绍一下BreakPad的使用方式。
2.3.1 BreakPad的实现功能
BreakPad主要提供两个个功能，NE的监听和回调，生成minidump文件，也就是dmp结尾的文件，另外提供两个工具，符号表工具和堆栈还原工具。
符号表工具：用于从so中提取出debug信息，获取到堆栈对应的符号表。
堆栈还原工具：用于将BreakPad生成的dump文件还原成符号，也就是堆栈偏移值。
这两个工具会在编译BreakPad源码的时候产生。
编译完之后会产生minidump_stackwalk工具，有些同学不想编译的话，Android Studio本身也提供了这个工具。
这个minidump_stackwalk程序在Android Studio的目录下面也存在，可以拿出来直接使用，如果不想编译的话，直接到该目录下面取即可，Mac路径为：
?1/Applications/Android Studio.app/Contents/bin/lldb/bin/minidump_stackwalk
2.3.2 BreakPad的捕获原理
由上述可以得知，BreakPad在应用发生NE崩溃时，可以将NE对应的minidump文件写入到本地，同时会回调给应用层，应用层可以针对本次崩溃做一些处理，达到捕获统计的作用，后续将minidump文件上传之后结合minidump_stackwalk以及addr2line工具可以还原出实际堆栈，示意图如下：
在应用发生NE时，BreakPad会在手机本地生成一个dump文件，如图所示：
得到了以上文件，我们只能知道应用发生了NE，但是这些文件其实是不可读的，需要解析这些文件。
下面着重讲一下如何分析上面产生的NE：
2.3.3 解析dump文件
1、获取NE崩溃的dump文件，将刚才得到的minidump_stackwalk和dump文件放在同一个目录，也可以不放，填写路径的时候填写绝对路径即可。
然后在该目录下的终端窗口执行以下命令，该命令表示用minidump_stackwalk解析dump文件，解析后的信息输出到当前目录下的crashLog.txt文件。
?1./minidump_stackwalk xxxxxxxx.dmp //代码效果参考：http://www.lyjsj.net.cn/wz/art_22684.html
>crashLog.txt2、执行完之后，minidump_stackwalk会将NE的相关信息写到crashLog.txt里面，详细信息如图所示：
3、根据解析出的NE信息，关注图中红框，可以得知，这个崩溃发生的 libbreakpad-core.so 里面，0x161a0代表崩溃发生在相对根位置偏移161a0的位置
2.3.4 获取崩溃堆栈
1、利用之前提到的addr2line工具，可以根据发生Crash的so文件以及偏移地址（0x161a0）可以得出产生crash的方法、行数和调用堆栈关系。
2、在其根目录对的终端窗口运行以下命令。
?12345arm-linux-androideabi-addr2line -C -f -e ${SOPATH} ${Address}-C -f //打印错误行数所在的函数名称-e //打印错误地址的对应路径及行数${SOPATH} //so库路径${Address} //需要转换的堆栈错误信息地址，可以添加多个，但是中间要用空格隔开，例如：0x161a0
3、如下图是真实运行的示例
?123aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 0x161a0Crash()/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111
由上图可以知道，该崩溃发生在breakpad.cpp文件的第111行，函数名是Crash()，与真实的文件一致，崩溃代码如下：
?123456789101112131415161718192021void Crash() { volatile int a = (int ) (NULL); a = 1; //此处在代码里是111行} extern ""C""JNIEXPORT void JNICALLJava_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo(JNIEnv env, jobject instance, jstring mLaunchInfoStr_) { DOTRY { Crash(); const char *mLaunchInfoStr = env->GetStringUTFChars(mLaunchInfoStr, 0); launchinfo = (char *) mLaunchInfoStr;// env->ReleaseStringUTFChars(mLaunchInfoStr, mLaunchInfoStr); } DO_CATCH(""updateLaunchInfo""); }
基于以上，便可以通过应用收集的dump文件解析的NE的详细堆栈信息。
三、so 符号表的提取
3.1 提取 so 的符号表
通过以上内容，我们知道，so中包含了一些debug信息，又叫做符号表，那么我们如何将这些debug信息单独剥离出来呢，ndk也给我们提供了相关的工具。
?1234aarch64架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdumparm架构/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-objdump
如下是命令运行的方式，通过此命令，可以将so中的debug信息提取到文件中。
?1promote:~ njvivo$ aarch64-linux-android-objdump -S libbreakpad-core.so > breakpad.asm
3.2 符号表分析
3.2.1 直接分析
如下图所示就是输出的符号表文件，结合上面的log以及下面的符号表文件，我们同样可以分析出堆栈。
如log中所示，已经表明了崩溃地址是161a0，而161a0对应的代码是a=1,由上面的分析我们已经知道该崩溃是在breakpad.cpp的111行，也就是a=1的位置，完全符合预期。
?123backtrace:#00 pc 00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)"
