crashpad通過接管崩潰處理流程生成minidump文件并上傳服務器從而大幅降低崩潰率。其核心在于提高崩潰捕獲可靠性、生成包含線程堆棧和寄存器信息的minidump文件、配置符號服務器解析地址為函數名、內置重試機制確保上傳成功。接入步驟包括集成庫、初始化設置存儲路徑與上傳url、配置符號服務器、處理上傳結果。在多線程環境下，crashpad暫停所有線程、收集各線程堆棧信息、生成綜合minidump文件。自定義內容可通過annotation添加鍵值對、實現自定義exceptionhandler、或向minidump寫入自定義stream。性能開銷主要來自崩潰捕獲、minidump生成與上傳，可通過選擇minidump類型、限制annotation大小、異步上傳、設置采樣率優化。無網絡時可配置本地存儲并在恢復后手動上傳。相比breakpad，crashpad采用多進程架構、支持更多平臺、功能更強且持續維護。調試集成問題可通過查看日志、使用調試器、檢查minidump文件、配合符號服務器進行分析。
崩潰報告，簡單來說，就是應用崩潰后，收集信息并上報，方便開發者定位和修復問題。Crashpad，則是Google開源的一個崩潰報告庫，跨平臺支持是它的一個亮點。用Crashpad，的確能大幅降低崩潰率，90%只是個說法，但效果確實顯著。
使用Crashpad大幅降低崩潰率
Crashpad的核心在于它能接管崩潰處理流程，生成minidump文件，然后上傳到服務器。這個過程的關鍵點在于：
-
崩潰捕獲的可靠性：傳統的崩潰捕獲機制在某些情況下可能會失效，而Crashpad通過自身的設計，提高了崩潰捕獲的成功率。
-
Minidump文件的詳細程度：Minidump文件包含了崩潰時的線程堆棧、寄存器信息、模塊列表等，這些信息對于定位問題至關重要。Crashpad可以配置生成更詳細的minidump，但也會增加文件大小。
-
上傳的成功率：即使生成了minidump，如果無法成功上傳到服務器，也無法發揮作用。Crashpad內置了上傳機制，并且可以配置重試策略，確保上傳成功。
-
符號文件（symbol Files）：有了minidump，還需要符號文件才能將內存地址解析為函數名和行號。Crashpad需要配合符號服務器使用，確保能夠獲取到正確的符號文件。
具體來說，接入Crashpad的步驟大致如下：
-
集成Crashpad庫：將Crashpad庫添加到你的項目中，這通常涉及到修改構建腳本（例如CMakeLists.txt）。
-
初始化Crashpad：在應用程序啟動時，初始化Crashpad，指定minidump的存儲路徑和上傳服務器的URL。
-
配置符號服務器：配置符號服務器，確保Crashpad能夠找到正確的符號文件。
-
處理上傳結果：在服務器端，接收并處理上傳的minidump文件，生成崩潰報告。
Crashpad如何處理多線程環境下的崩潰？
多線程環境下的崩潰往往更加復雜，因為崩潰可能發生在任何線程中，并且可能受到其他線程狀態的影響。Crashpad在處理多線程崩潰時，會捕獲所有線程的堆棧信息，這使得開發者可以了解崩潰發生時整個應用程序的狀態。
更具體地說，Crashpad會：
-
暫停所有線程：當一個線程發生崩潰時，Crashpad會暫停所有其他線程，以防止它們修改崩潰線程的狀態。
-
收集所有線程的堆棧信息：Crashpad會遍歷所有線程，收集它們的堆棧信息，包括函數調用鏈、寄存器值等。
-
生成包含所有線程信息的minidump：Crashpad會將收集到的所有線程信息寫入minidump文件。
這種方式確保了開發者能夠獲取到盡可能多的信息，從而更容易定位問題。但需要注意的是，暫停所有線程可能會導致應用程序短暫的無響應，因此需要權衡性能和可靠性。
如何自定義Crashpad的崩潰報告內容？
雖然Crashpad默認會收集很多有用的信息，但在某些情況下，你可能需要自定義崩潰報告的內容，例如添加一些應用程序特定的信息，或者過濾掉一些敏感數據。
Crashpad提供了自定義崩潰報告內容的能力，主要通過以下幾種方式：
-
Annotation：Annotation是一種鍵值對，你可以使用Crashpad提供的API，在應用程序中添加Annotation。當發生崩潰時，Crashpad會將這些Annotation添加到minidump文件中。
-
自定義ExceptionHandler：你可以實現自己的ExceptionHandler，并在其中添加自定義的崩潰處理邏輯。例如，你可以記錄一些日志信息，或者執行一些清理操作。
-
MinidumpStream：你可以向minidump文件中添加自定義的Stream，Stream是一種二進制數據塊，你可以將任何你想添加的數據寫入Stream中。
例如，假設你想在崩潰報告中添加應用程序的版本號，你可以這樣做：
#include "client/crashpad_client.h" #include "client/crash_report_database.h" int main() { crashpad::CrashpadClient client; std::map<std::string, std::string> annotations; annotations["version"] = "1.2.3"; client.SetAnnotations(annotations); // ... 應用程序的其他代碼 ... }
這段代碼會在崩潰報告中添加一個名為”version”，值為”1.2.3″的Annotation。
Crashpad的性能開銷如何？
任何崩潰報告機制都會帶來一定的性能開銷，Crashpad也不例外。主要的性能開銷來自于以下幾個方面：
-
崩潰捕獲：Crashpad需要接管崩潰處理流程，這會帶來一定的開銷。
-
Minidump生成：生成minidump文件需要讀取內存、線程堆棧等信息，這會消耗CPU和內存資源。
-
Minidump上傳：上傳minidump文件需要網絡帶寬，并且可能會影響應用程序的響應速度。
為了降低性能開銷，可以采取以下措施：
-
選擇合適的Minidump類型：Crashpad支持多種Minidump類型，例如Mini、MiniPlus、Full等。Mini類型的Minidump文件最小，性能開銷也最小，但包含的信息也最少。Full類型的Minidump文件最大，性能開銷也最大，但包含的信息也最多。
-
限制Annotation的數量和大小：Annotation會增加Minidump文件的大小，因此需要限制Annotation的數量和大小。
-
異步上傳Minidump：可以將Minidump上傳操作放在后臺線程中執行，以避免阻塞主線程。
-
采樣率：可以設置采樣率，只對一部分崩潰生成崩潰報告。
總的來說，Crashpad的性能開銷是可以接受的，尤其是在考慮到它所帶來的好處（例如大幅降低崩潰率）之后。
如何在沒有網絡的環境下使用Crashpad？
有些應用程序可能需要在沒有網絡的環境下運行，例如嵌入式設備。在這種情況下，Crashpad仍然可以發揮作用，但需要進行一些額外的配置。
Crashpad的核心功能是生成minidump文件，即使沒有網絡，Crashpad仍然可以生成minidump文件并將其存儲在本地。當網絡恢復時，你可以手動上傳這些minidump文件到服務器。
具體來說，你需要：
-
配置本地存儲路徑：在初始化Crashpad時，指定一個本地存儲路徑，用于存儲minidump文件。
-
實現手動上傳機制：當網絡恢復時，你需要實現一個手動上傳機制，將本地存儲的minidump文件上傳到服務器。
例如，你可以創建一個后臺線程，定期檢查本地存儲路徑，如果發現有新的minidump文件，就嘗試上傳。
#include "client/crashpad_client.h" #include "client/crash_report_database.h" #include <thread> #include <chrono> #include <filesystem> void UploadMinidumps() { while (true) { // 檢查本地存儲路徑 std::filesystem::path minidump_path("/path/to/minidumps"); for (const auto& entry : std::filesystem::directory_iterator(minidump_path)) { if (entry.is_regular_file() && entry.path().extension() == ".dmp") { // 上傳minidump文件 UploadFile(entry.path().string(), "https://your.upload.server"); // 刪除已上傳的文件 std::filesystem::remove(entry.path()); } } // 等待一段時間 std::this_thread::sleep_for(std::chrono::minutes(5)); } } int main() { crashpad::CrashpadClient client; std::map<std::string, std::string> annotations; annotations["version"] = "1.2.3"; client.SetAnnotations(annotations); // 啟動上傳線程 std::thread upload_thread(UploadMinidumps); upload_thread.detach(); // ... 應用程序的其他代碼 ... }
這段代碼會創建一個后臺線程，每隔5分鐘檢查一次本地存儲路徑，如果發現有新的minidump文件，就嘗試上傳。
需要注意的是，你需要自己實現UploadFile函數，該函數負責將minidump文件上傳到服務器。
Crashpad與Breakpad的區別是什么？
Crashpad和Breakpad都是Google開源的崩潰報告庫，它們有很多相似之處，但也有一些重要的區別。
-
架構：Crashpad采用了多進程架構，而Breakpad采用了單進程架構。這意味著Crashpad的崩潰處理過程是在一個獨立的進程中進行的，而Breakpad的崩潰處理過程是在應用程序的進程中進行的。多進程架構使得Crashpad更加穩定可靠，因為即使崩潰處理進程崩潰了，也不會影響應用程序的運行。
-
跨平臺支持：Crashpad對跨平臺的支持更好，它可以支持windows、macos、linux、android等多個平臺。Breakpad對跨平臺的支持相對較弱。
-
功能：Crashpad提供了更多的功能，例如自定義崩潰報告內容、異步上傳Minidump等。
-
維護：Crashpad目前仍在積極維護中，而Breakpad已經停止維護。
總的來說，Crashpad是Breakpad的替代品，它具有更好的架構、更廣泛的跨平臺支持、更多的功能和更積極的維護。如果你正在尋找一個崩潰報告庫，Crashpad是一個更好的選擇。
如何調試Crashpad集成？
在集成Crashpad的過程中，可能會遇到各種各樣的問題，例如崩潰報告無法生成、崩潰報告無法上傳、符號文件無法找到等。為了解決這些問題，你需要掌握一些調試技巧。
-
查看日志：Crashpad會生成日志，你可以通過查看日志來了解Crashpad的運行狀態。日志中包含了Crashpad的各種信息，例如崩潰捕獲、Minidump生成、Minidump上傳等。
-
使用調試器：你可以使用調試器來調試Crashpad的代碼，例如GDB、LLDB、visual studio Debugger等。通過調試器，你可以單步執行Crashpad的代碼，查看變量的值，從而了解Crashpad的運行過程。
-
檢查Minidump文件：你可以使用Minidump分析工具來檢查Minidump文件，例如WinDbg、GDB、LLDB等。通過Minidump分析工具，你可以查看崩潰時的線程堆棧、寄存器信息、模塊列表等，從而了解崩潰的原因。
-
使用符號服務器：你可以使用符號服務器來查找符號文件，例如microsoft Symbol Server、Mozilla Symbol Server等。通過符號服務器，你可以將內存地址解析為函數名和行號，從而更容易定位問題。
例如，你可以使用WinDbg來分析Minidump文件：
windbg -z crash.dmp
然后，你可以使用!analyze -v命令來分析崩潰原因：
0:000> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* ... (省略大量輸出) ... MODULE_NAME: test IMAGE_NAME: test.exe FAILURE_BUCKET_ID: NULL_POINTER_READ ... (省略大量輸出) ...
這段代碼會使用WinDbg打開crash.dmp文件，并使用!analyze -v命令來分析崩潰原因。分析結果會告訴你崩潰的模塊名、異常類型等信息。
