技術乾貨 | mPaaS 框架下如何使用 Crash SDK 對閃退進行分析？

目前 mPaaS Android 是使用的是 Crash SDK 對閃退進行的處理，Crash SDK 是 Android 平臺上一款功能強大的崩潰日誌收集 SDK，有着極高的崩潰收集率和完整、全面的崩潰日誌信息，生成的日誌內容很是利於問題的跟進和解決。

在咱們的平常運維中，常常遇到一些閃退，沒法直接從閃退堆棧看到緣由，尤爲是一些非 Java 的 Native 的閃退，這裏分享下在 mPaaS 框架下怎麼使用 Crash SDK 對閃退進行分析。

 

 

閃退報文分析工具介紹

對於 mPaaS 的用戶，從 MAS 上閃退分析平臺導出的通常是原始的閃退信息，閃退信息比較多，若是直接閱讀會比較困難，使用者能夠經過下載 Chrome 的插件 LogAnalyzer。

LogAnalyzer 會將 Crash SDK 生成的日誌文本內容轉化成可視效果較強的 HTML 頁面展示，功能仍是很強大的，主要包含：

1. 高亮顯示日誌中重點信息，並使用不一樣顏色區分；
2. 支持日誌內容總體結構預覽，快速定位重點內容；
3. 常見崩潰緣由提醒；

安裝好 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 操做觸發了底層的空指針，從而致使初始化異常，最後觸發了閃退。解決方案就是臨時關閉預建立，從而規避了閃退。

從上面的案例咱們能夠看出：

1. Native 的閃退不必定是 Native 模塊的緣由致使的，有多是因爲 Java 致使的異常，從而致使 Native 閃退；
2. 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 移動分析服務：經過多端埋點數據的採集與分析，實現產品核心指標監控。

支持應用穩定性分析，包括閃退監控、異常監控、性能監控及用戶診斷功能，幫助開發人員及時發現、定位問題。

幫助企業更好的完成業務監控、用戶洞察與行爲分析，指導產品迭代，精細化產品運營，輔助營銷決策，加速業務商業化。

點擊瞭解MAS更多資訊

 

- END -