有哪些比較好的Android異常（crash、ANR、內存泄漏等等）處理機制？

01-13

周末看了英語流利說 Android 架構演進這篇文章，其中對文章中的監控系統體系比較感興趣。
對於開發者來說，比較頭疼的就是每當用戶反饋了bug，但卻無法復現用戶所描述的情景，但又聽說有些公司的APP只要用戶反饋bug，就可以復現用戶出現bug的過程，很快定位到bug，他們是怎麼做到的呢？有什麼樣的方案可以很好地解決這個問題呢？（用友盟、bugly等第三方SDK？或者自己內部實現一套異常上報方案？）

今天和很多小夥伴思考討論了關於[客戶端開發]中 log 代碼的問題，在這裡總結如下：

log 代碼是必須的，log 在開發，調試，調優，用戶數據等等方面都很重要
真正發揮作用的 log，都是「事前」的，在能定位問題的那次 bug 發生之前加上的 log，會在這次 bug 中幫助我們定位問題
複雜情況下，要能找出幾個關鍵點，記下關鍵數據（必須能夠把問題鎖定在很小範圍，且一定可以分析出直接原因），寫代碼之前就要胸有成竹，明確關鍵點（更甚者，先理清框架、編碼、測試，通過測試之後再實現細節，當然 log 還是不可少）
簡單情況、複雜情況非關鍵點，堅決不允許 log，代碼污染絕不容忍
和團隊成員一起確定規範，並嚴格遵守（code review）
log 採集

相關 log 需要集中在一起，再拿到集中分析，單條 log 基本沒用（這一功能很可能沒有好輪子）
注意非同步化、批量保存、本地存儲與加密、上傳時機等

最後聲明（廣告）一下，以上內容總結自 Add1bit，stay，diycode 的討論。

常規的 Crash / ANR 問題，業內諸如 Crashlytics 之類的工具已經能很好的處理了，哪家其實都差不多，Bugly 可能可以多記錄一個 ANR。

但同樣是這些工具，也有不一樣的用法，比如 Crashlytics 默認抓取的信息如果不夠用，它還提供了介面供你補充各種環境參數、各種現場 Log, 將異常出現之前的環境儘可能記錄完整，所以快速捉蟲的關鍵在於：充分還原異常出現之前的現場環境。

比如：

不要隨便把異常吃掉不上拋；
分別處理每一個特定異常而非通用異常；
如果請求時因 json 數據格式錯誤導致了異常，就務必要把有問題的 json 全文打出來；
監控並輸出 Activity 生命周期；
。。。

只要現場環境足夠充分，再在出現問題時通過一些工具上傳信息就好，這裡指的問題，不局限於 Crash / ANR, 也可以是代碼進入了一些不影響程序運行的異常邏輯流，總之是你覺得有問題的地方，定義好何謂「異常」，充分還原「異常」出現之前的現場環境，捉蟲自然就快。

關於還原「異常」出現之前的現場環境，我之前介紹過 "appsee" 這個大殺器，想像一下用戶 Crash 之前的操作視頻都給你了，還想要怎樣？

最後想說一下，預防勝於治療。平時就要對代碼質量嚴格要求，充分解耦，結構設計清晰，異常處理規範，重視各種靜態分析工具找出的「小」問題，做好單元測試等等，這些基礎工作都做到位了，即便有問題，定位也是分分鐘的事情，很少出現詭異的 Bug；否則代碼像一團麵條，即便各種環境信息充分，甚至當你面重現了問題，也未必能很快搞得清緣由。

crash/anr都可以通過騰訊的https://bugly.qq.com/v2/之類的平台能夠實現.內存泄漏的話.接入一下GitHub - square/leakcanary: A memory leak detection library for Android and Java.吧.

當然自己也可以用as來dump一下來分析.當然想更加詳細還是老老實實MAT看咯.

拋個磚。

大家都知道Android是基於消息機制的，所以基本所有的邏輯大都會在looper隊列有序處理。

然後Looper對於每個消息執行前後都會記錄列印，所以我們可以傳入一個printer，監聽主線程執行。當某個事件處理超過3s或者4s(即將ANR)的時候，輸出主線程任務棧到到日誌。

剩下你就知道怎麼定位問題了。

—————

我才不會說該思路已經有實際應用了。&>_&<

實際項目上遇到過這種情況，客戶會內置一個可以收集異常log信息的應用，可以把不同平台（mtk,qcom,sprd）的log信息打包上傳到對應的伺服器,拿到log信息就可以分析具體問題了。比如mtk平台收集的mtklog文件夾中，有一個文件夾aee_exp專門收集crash異常信息。可以通過mediatek logview工具打開對應文件夾中的dbg文件，就可以看到對應的異常信息，如下圖所示:

android:largeHeap="true"

對不起我很菜

之前和微信的童鞋討論過這點，所以深深得同意湯濤的最後的說法：「預防勝於治療」，例如優測、testin這些就能幫助出街前的測試，但是誰又敢說經過測試你就一定敢拍著胸脯說，我的APP完全沒有crash、ANR、卡頓和內存泄漏？

所以線上的監控是必不可少的，重複造輪子的事不適合也不建議團隊去做（如果真有餘力，請做專業的事，把APP本身做好！），成本就不說，可能做得也不全面，而且容易出錯。所以，專業的事情請讓專業的人去做吧！

個人推薦Bugly和Crashlytic，Bugly的專業度和服務確實很不錯，苦逼的碼農們可以體驗一吧，誰用誰知道啦

應該說，一般大公司都會有自己搭建的數據平台，用於分析用戶行為，以及bug反饋。並且app端會有相應代碼，每次應用啟動時會上傳crash log到後台，後台會根據用戶所屬平台，再將相應crash記錄推送到對應app開發團隊，再由團隊解決，然後反饋給數據平台顯示crash狀態為解決。

團隊協作由於有了這樣的數據平台以及git工具，所以開發和維護效率會有很大提升。

我做預裝版本，不得不說友盟，bugly確實好用。但是初始化的時候會出現流量偷跑的問題，工信部不讓用，從此我基本算瞎了。

大家說說你各自解決方法是什麼，學習學習

一般app都會添加用戶行為記錄，然後上傳至伺服器端進行分析，然後對模塊進行調整，提高用戶體驗，提高維護效率。在這個過程中會添加一些輸出日誌，應用產錯後提交日誌一般是可以定位錯誤的（新人，不知道對不）

在我電腦跑沒問題啊！

在我測試機跑沒問題啊!

bug tags好像有這樣的功能