聲網崩潰資料的自動化閉環處理

01 崩潰資訊的自動化處理是趨勢

程式崩潰是由於發生某種嚴重錯誤而導致程式無法繼續執行下去，從而異常退出的現象，它是質量保證過程中遇到最頻繁的問題之一，通常這類問題需要我們非常重視對待。當使用者在使用你的 APP 遇到頻繁閃退或者崩潰時，會造成大量使用者流失。

引起程式崩潰的原因有很多，通常是因為以下幾點：

1.程式邏輯問題，發生瞭如陣列越界、堆疊溢位、空指標異常等問題；

2.裝置相容性問題，因為裝置和系統的多樣性，特別是安卓系統，可能達到上千種，很難做到完全的裝置相容；

3.記憶體管理錯誤，程式內部存在記憶體洩漏問題，長時間的執行和無法釋放物件的累積，導致了記憶體溢位，最終發生程式崩潰；或者是程式所需要的執行記憶體超過了裝置限制等。

現實生產過程中，因為多種版本的迭代，可能會讓我們面對海量的崩潰資料，需要對每一條資料逐個的去進行人工校驗，篩選出重複問題，保留有效資料，並且提交 BUG 進行跟蹤。不僅費時費力，效率低下，還很有可能會引發嚴重問題的疏漏。所以建立一條便捷高效的自動化的閉環處理流程十分必要。

02 常見解決方案的不足

以往常見的解決方案是整合騰訊的 Bugly SDK，用來捕獲 Android 或者 iOS APP 中的崩潰資訊。Bugly 提供了一套完整的崩潰資訊監控和解決方案。開發者將移動應用整合 Bugly，然後通過崩潰監控後臺服務，可以方便的展示出使用者在使用 APP 過程中出現的崩潰/ANR 等問題，並根據上報的崩潰資訊快速定位和解決問題。但是這種方案並不能應用在桌面應用上(Windows/Mac 等)，而且 Bugly 目前也沒有開放第三方介面，讓我們獲取崩潰資料列表以便於進行自動化分析處理。崩潰資訊都要人工去進行處理過濾，最終達到的效果並不能讓人滿意。

03 跨平臺的崩潰自動化閉環處理方案

為了解決上述問題，Agora 開發了一套跨平臺(Android/iOS/Mac/Windows)的崩潰資訊採集處理方案。當發生崩潰的時候，Agora 的 SDK 會將相關資訊（版本號、平臺、編譯號、崩潰偏移地址、符號表地址、DMP 檔案連結等）提交到我們的後臺系統，後臺通過繫結的堆疊資訊和符號表進行符號化，提取出地址和符號的對應關係，進而還原成開發人員可以理解的崩潰堆疊資訊。

符號化完成之後，系統會判斷當前的 SDK 版本是不是已經提交了相同問題的 JIRA，如果沒有提交，就新增 JIRA。在新增 JIRA 的過程中還可以根據崩潰的模組指派到對應的負責人，比如最終定位到是 audio 模組的崩潰，就指定到 audio 模組開發負責人，video 模組的崩潰，就指定到 video 模組的負責人，網路模組的崩潰，就指定到網路模組的負責人，優化了手動指派負責人的過程、大大提升了問題處理的效率。如果當前分析的結果是已經提交過 JIRA，則自動關聯到相關的問題上並更新對應問題的崩潰次數。整個處理的流程如下圖所示：

怎麼區分一個版本相同的問題是否提交過呢？目前有兩個維度，一個是通過編譯號和崩潰偏移地址確認，如果多個崩潰資料的編譯號和崩潰偏移地址是一致的，那麼我們就將這幾個崩潰資料歸類為同一個問題，提交 JIRA 的時候會彙總同一個問題產生的次數。但是經過一段時間的實踐，我們發現很多情況下同一個版本的編譯號和崩潰偏移地址不一致，但有可能是由於同一個問題導致的。所以我們需要引入第二個維度，提取出堆疊詳情進行分析。我們把能夠解析出來的行的資訊拼接起來，得到拼接字串 Hash 值，然後根據 Hash 值是否相同去進行判斷，同樣的問題是否已經有過提交記錄。通過兩個維度的篩選，可以有效的去除重複問題的 JIRA 提交，並且可以更有效的進行崩潰數量的統計。其中我們可以制定一些不同的 Hash 生成方案來進行重複崩潰問題的過濾，可以通過最為寬鬆的方案，如通過最終崩潰的類名+方法名來生成 Hash；嚴格的方案如根據最終崩潰的檔名+模組名+類名+方法名+引數名來生成 Hash。下圖是我們實踐過程中，通過自動化解析崩潰資料提交的一個 JIRA：