為什麼使用Google Breakpad？
在項目開發中，我們經常需要引入一些第三方的.so檔案或者是寫一些Native代碼，但是當Native代碼出現crash後，對crash的追蹤和定位一直是一個比較艱難的事情。
Google Breakpad是一套完整的工具集，從Crash的捕獲到Crash的dump，都提供了相對應的工具。它記錄了崩潰時的.dump檔案，無論我們是在本地或者發送到伺服器端，都可以用相對應的工具來解析.dump檔案幫助我們查找C和C++堆棧蹤迹。
Google BreakPad簡介
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。
引入Google BreakPad到項目，并解析.dump檔案
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
最後就能看到具體是哪個類下的哪一行報錯了。