目前 mPaaS Android 是使用的是 Crash SDK 對閃退進行的處理，Crash SDK 是 Android 平臺上一款功能強大的崩潰日誌收集 SDK，有着極高的崩潰收集率和完整、全面的崩潰日誌信息，生成的日誌內容非常利於問題的跟進和解決。
在我們的日常運維中，經常遇到一些閃退，無法直接從閃退堆棧看到原因，尤其是一些非 Java 的 Native 的閃退，這裏分享下在 mPaaS 框架下怎麼使用 Crash SDK 對閃退進行分析。
閃退報文分析工具介紹
對於 mPaaS 的用戶，從 MAS 上閃退分析平臺導出的一般是原始的閃退信息，閃退信息比較多，如果直接閱讀會比較困難，使用者可以通過下載 Chrome 的插件 LogAnalyzer。
LogAnalyzer 會將 Crash SDK 生成的日誌文本內容轉化成可視效果較強的 HTML 頁面展現，功能還是很強大的，主要包含：
- 高亮顯示日誌中重點信息，並使用不同顏色區分；
- 支持日誌內容整體結構預覽，快速定位重點內容；
- 常見崩潰原因提醒；
安裝好 Chrome 插件後，還需要做以下配置
1. 修改閃退文件後綴爲 .txt
由於 MAS 上默認下載的文件後綴是.dat，需要改爲.txt，否則 LogAnalyzer 會不識別。
2. 修改插件配置
由於 Chrome 默認權限限制，任何 Chrome 插件默認都不能訪問文件網址，需要在 Chrome 插件中進行如下操作。
1.打開 Chrome 插件管理頁面 chrome://extensions/
2.找到 LogAnalyzer 插件，點擊 “詳細信息" 進入設置：
3.找到允許訪問文件網址選項，並勾選；
4.打開或者刷新日誌頁面，LogAnalyzer 就生效了。
3. 生效效果
把日誌文件直接拖到 Chrome 後，可以看到右邊插件生效後，可以通過不同顏色顯示閃退信息的各個字段。
首次打開後的使用說明如下：
正常查看閃退截圖如下：
閃退分析舉例
我們經常在日常運維中遇到一些非 Java 的 Native 模塊閃退，比如 UC。這種時候很多時候只能去聯繫 UC 團隊進行支撐，其實很多場景下，閃退的根因並不是 UC，只是最後的閃退點在 UC。
以最近日常運維中比較常遇到的 UC 內核的閃退爲例，對一些案例的處理分享如下。
1. Java 空指針導致 UC 閃退
我們在閃退點上可以看到以下閃退（已經隱藏客戶 apk 相關信息)，如果只是從這看我們暫時沒有任何線索，我們繼續往下看日誌：
當看到 logcat 節點信息的時候，我們發現了線索，首先我們看到關鍵字：begin to generate native report，表示當前是閃退日誌上報的日誌，我們再往前看，logcat 節點裏打印了異常堆棧信息。
從堆棧信息可以看到，是由於 precreate 操作觸發了底層的空指針，從而導致初始化異常，最後觸發了閃退。解決方案就是臨時關閉預創建，從而規避了閃退。
從上面的案例我們可以看出：
- Native 的閃退不一定是 Native 模塊的原因導致的，有可能是由於 Java 導致的異常，從而導致 Native 閃退；
- begin to generate native report 附近可以看閃退相關的 logcat 信息，協助定位閃退的一些上下文日誌。
2. 上層 OOM 導致 UC 閃退
首先我們看上報的閃退點的日誌如下圖所示，閃退在了 RenderThread 裏，也是毫無頭緒。
我們繼續硬着頭皮往下看，在 logcat 節點裏查找 begin to generate native report 上報節點，我們看到了大量的底層 OOM 的異常日誌，基本大概率確定是 OOM 的原因了。
剩下的就是查找 OOM 是哪裏觸發的。
點擊閃退裏的內存節點，基本原因就比較清晰了，當前手機的 Vmsize 基本已經到最大了，我們知道對於 32 位的進程，APP 可使用的 VmSize 最大爲 3GB，不過當運行在 64 位 CPU 上時，VmSize 最大可超過 3GB，接近 4GB。
但是由於內核需要佔據一部分，以及不同的 ROM 版本的差別，我們發現有以下規律：Android 8.1.0 及之後的系統，大部分 native oom crash 發生時 VmSize 分佈在 3.5 - 3.9 G 的位置，相對較爲集中。所以下面的案例的解決思路就變成了怎麼解決 OOM 了。
3. FD 誤關導致 UC 閃退
上報的日誌如下圖所示，我們大概只能看出 SIGILL 有可能是主動崩潰，崩潰 ILL_ILLOPC 表示非法操作。
然後我們繼續看 logcat 節點的 begin to generate native report, 基本確認原因是因爲 UC 使用的 FD 對象被其他程序關閉。
隨後 UC 提供了帶 FDscan 的工具包，通過我們復現後發現，是由於 UC 調用 shouldIntercept 回調的輸入流對象被其他模塊 close 掉了，導致 UC 使用的時候發現 FD 對象已經被關閉，從而做了崩潰處理。最後的處理方案就變成了用戶解決其他模塊的誤關 FD 的問題。
總結
綜合以上的 Case 分析，在遇到 Native 模塊閃退的時候，一般如果從直接的閃退堆棧看不出原因的時候，不要心急，可以搜索 begin to generate native report 找到崩潰上下文，多看看 logcat 閃退上下文的日誌，會有一些收穫，同時對於 oom 類型的問題，可以結合當前內存統計來看。
關於 mPaaS MAS
MAS 移動分析服務：通過多端埋點數據的採集與分析，實現產品核心指標監控。
支持應用穩定性分析，包括閃退監控、異常監控、性能監控及用戶診斷功能，幫助開發人員及時發現、定位問題。
幫助企業更好的完成業務監控、用戶洞察與行爲分析，指導產品迭代，精細化產品運營，輔助營銷決策，加速業務商業化。
延伸閱讀
- END -