在项目开发中，我们经常需要引入一些第三方的.so文件或者是写一些Native代码，但是当Native代码出现crash后，对crash的追踪和定位一直是一个比较艰难的事情。
Google Breakpad是一套完整的工具集，从Crash的捕获到Crash的dump，都提供了相对应的工具。它记录了崩溃时的.dump文件，无论我们是在本地或者发送到服务器端，都可以用相对应的工具来解析.dump文件帮助我们查找C和C++堆栈踪迹。
Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合。
Breakpad由三个主要组件：
client，以library的形式内置在我们的应用中，当崩溃发生时写 minidump文件。
symbol dumper, 读取由编译器生成的调试信息（debugging information），并生成 symbol file。
processor， 读取 minidump文件 和 symbol file ，生成可读的c/c++ Stack trace。
简单来说就是一个生成 minidump，一个生成symbol file，然后将其合并处理成可读的Stack trace。
1.利用Android新建一个项目，具体参考的Sample,可以直接导入Android Studio中，这个项目是采用CMakeLists.txt来配置的。
2.在真机中运行项目会出现下面的界面，点击按钮应用闪退。
3.闪退之后会在手机的文件管理器中会生成一个crashDump目录，里面有一个.dump文件
4.在Android Studiod的安装目录\bin\lldb\bin中存在一个minidump_stackwalk.exe的可执行文件，我们现在需要用这个工具对.dump文件进行解析，并将解析的结果写到crash.txt文件中
minidump_stackwalk.exe f7ab957b-326b-4772-160d079e-1f44738d.dmp >crash.txt
5.成功解析文件
6.从dump文件解析出来的信息来看，crash原因是SIGSEGV，根据文章Android 平台 Native 代码的崩溃捕获机制及实现的介绍，我们可知Crash reason: SIGSEGV代表哪种类型的错误：
Crash reason: SIGSEGV //是当一个进程执行了一个无效的内存引用，或发生段错误时发送给它的信号。 Crash address: 0x0 Process uptime: not available Thread 0 (crashed) //crash 发生时候的线程 0 libcrash-lib.so + 0x7b2 //发生 crash 的位置和寄存器信息7.有了具体的寄存器信息，我们就进行符号解析，可以使用Android NDK中提供的addr2line来根据地址进行一个符号反解的过程，该工具在Android SDK目录下可以找到。
工具链的选择要根据.so的类型来决定，看解析后的文件，有显示CPU信息。下面是NDK20的工具链目录：
如果是arm-64位的so，解析是需要使用aarch64-linux-android-4.9下的工具链。如果是arm-32位的so，解析是需要使用arm-linux-androideabi-4.9下的工具链。如果是x86-64位的so，解析是需要使用x86_64-4.9下的工具链。如果是x86-32位的so，解析是需要使用x86-4.9下的工具链
8.这里，因为CPU信息是armv7，所以选择arm-linux-androideabi-4.9下的工具链。我们将项目中build目录下的arm-v7a对应的libcrash-lib.so(app\build\intermediates\transforms\mergeJniLibs\debug\0\lib\armeabi-v7a\libcrash-lib.so)拷贝到arm-linux-androideabi-4.9下的工具链目录(arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin)中，然后执行如下命令：
arm-linux-androideabi-addr2line.exe -f -C -e libcrash-lib.so 0x7b2最后就能看到具体是哪个类下的哪一行报错了。
