共計 2131 個字符，預計需要花費 6 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關 mPaaS 框架下是怎么使用 Crash SDK 對閃退進行分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
目前 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 的問題。
上述就是丸趣 TV 小編為大家分享的 mPaaS 框架下是怎么使用 Crash SDK 對閃退進行分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
