mPaaS框架下是怎么使用Crash SDK對(duì)閃退進(jìn)行分析

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)mPaaS框架下是怎么使用Crash SDK對(duì)閃退進(jìn)行分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

目前 mPaaS Android 是使用的是 Crash SDK 對(duì)閃退進(jìn)行的處理，Crash SDK 是 Android 平臺(tái)上一款功能強(qiáng)大的崩潰日志收集 SDK，有著極高的崩潰收集率和完整、全面的崩潰日志信息，生成的日志內(nèi)容非常利于問題的跟進(jìn)和解決。

在我們的日常運(yùn)維中，經(jīng)常遇到一些閃退，無法直接從閃退堆?？吹皆颍绕涫且恍┓?Java 的 Native 的閃退，這里分享下在 mPaaS 框架下怎么使用 Crash SDK 對(duì)閃退進(jìn)行分析。

閃退報(bào)文分析工具介紹

對(duì)于 mPaaS 的用戶，從 MAS 上閃退分析平臺(tái)導(dǎo)出的一般是原始的閃退信息，閃退信息比較多，如果直接閱讀會(huì)比較困難，使用者可以通過下載 Chrome 的插件 LogAnalyzer。

LogAnalyzer 會(huì)將 Crash SDK 生成的日志文本內(nèi)容轉(zhuǎn)化成可視效果較強(qiáng)的 HTML 頁面展現(xiàn)，功能還是很強(qiáng)大的，主要包含：

1. 高亮顯示日志中重點(diǎn)信息，并使用不同顏色區(qū)分；

2. 支持日志內(nèi)容整體結(jié)構(gòu)預(yù)覽，快速定位重點(diǎn)內(nèi)容；

3. 常見崩潰原因提醒；

安裝好 Chrome 插件后，還需要做以下配置

1. 修改閃退文件后綴為 .txt

由于 MAS 上默認(rèn)下載的文件后綴是.dat，需要改為.txt，否則 LogAnalyzer 會(huì)不識(shí)別。

2. 修改插件配置

由于 Chrome 默認(rèn)權(quán)限限制，任何 Chrome 插件默認(rèn)都不能訪問文件網(wǎng)址，需要在 Chrome 插件中進(jìn)行如下操作。

1.打開 Chrome 插件管理頁面 chrome://extensions/

2.找到 LogAnalyzer 插件，點(diǎn)擊 “詳細(xì)信息" 進(jìn)入設(shè)置：

3.找到允許訪問文件網(wǎng)址選項(xiàng)，并勾選；
4.打開或者刷新日志頁面，LogAnalyzer 就生效了。

3. 生效效果

把日志文件直接拖到 Chrome 后，可以看到右邊插件生效后，可以通過不同顏色顯示閃退信息的各個(gè)字段。

首次打開后的使用說明如下：

正常查看閃退截圖如下：

閃退分析舉例

我們經(jīng)常在日常運(yùn)維中遇到一些非 Java 的 Native 模塊閃退，比如 UC。這種時(shí)候很多時(shí)候只能去聯(lián)系 UC 團(tuán)隊(duì)進(jìn)行支撐，其實(shí)很多場景下，閃退的根因并不是 UC，只是最后的閃退點(diǎn)在 UC。

以最近日常運(yùn)維中比較常遇到的 UC 內(nèi)核的閃退為例，對(duì)一些案例的處理分享如下。

1. Java 空指針導(dǎo)致 UC 閃退

我們在閃退點(diǎn)上可以看到以下閃退（已經(jīng)隱藏客戶 apk 相關(guān)信息)，如果只是從這看我們暫時(shí)沒有任何線索，我們繼續(xù)往下看日志：

當(dāng)看到 logcat 節(jié)點(diǎn)信息的時(shí)候，我們發(fā)現(xiàn)了線索，首先我們看到關(guān)鍵字：begin to generate native report，表示當(dāng)前是閃退日志上報(bào)的日志，我們再往前看，logcat 節(jié)點(diǎn)里打印了異常堆棧信息。

從堆棧信息可以看到，是由于 precreate 操作觸發(fā)了底層的空指針，從而導(dǎo)致初始化異常，最后觸發(fā)了閃退。解決方案就是臨時(shí)關(guān)閉預(yù)創(chuàng)建，從而規(guī)避了閃退。

從上面的案例我們可以看出：

1. Native 的閃退不一定是 Native 模塊的原因?qū)е碌?，有可能是由?Java 導(dǎo)致的異常，從而導(dǎo)致 Native 閃退；

2. begin to generate native report 附近可以看閃退相關(guān)的 logcat 信息，協(xié)助定位閃退的一些上下文日志。

2. 上層 OOM 導(dǎo)致 UC 閃退

首先我們看上報(bào)的閃退點(diǎn)的日志如下圖所示，閃退在了 RenderThread 里，也是毫無頭緒。

我們繼續(xù)硬著頭皮往下看，在 logcat 節(jié)點(diǎn)里查找 begin to generate native report 上報(bào)節(jié)點(diǎn)，我們看到了大量的底層 OOM 的異常日志，基本大概率確定是 OOM 的原因了。

剩下的就是查找 OOM 是哪里觸發(fā)的。

點(diǎn)擊閃退里的內(nèi)存節(jié)點(diǎn)，基本原因就比較清晰了，當(dāng)前手機(jī)的 Vmsize 基本已經(jīng)到最大了，我們知道對(duì)于 32 位的進(jìn)程，APP 可使用的 VmSize 最大為 3GB，不過當(dāng)運(yùn)行在 64 位 CPU 上時(shí)，VmSize 最大可超過 3GB，接近 4GB。

但是由于內(nèi)核需要占據(jù)一部分，以及不同的 ROM 版本的差別，我們發(fā)現(xiàn)有以下規(guī)律：Android 8.1.0 及之后的系統(tǒng)，大部分 native oom crash 發(fā)生時(shí) VmSize 分布在 3.5 - 3.9 G 的位置，相對(duì)較為集中。所以下面的案例的解決思路就變成了怎么解決 OOM 了。

3. FD 誤關(guān)導(dǎo)致 UC 閃退

上報(bào)的日志如下圖所示，我們大概只能看出 SIGILL 有可能是主動(dòng)崩潰，崩潰 ILL_ILLOPC 表示非法操作。

然后我們繼續(xù)看 logcat 節(jié)點(diǎn)的 begin to generate native report, 基本確認(rèn)原因是因?yàn)?UC 使用的 FD 對(duì)象被其他程序關(guān)閉。

隨后 UC 提供了帶 FDscan 的工具包，通過我們復(fù)現(xiàn)后發(fā)現(xiàn)，是由于 UC 調(diào)用 shouldIntercept 回調(diào)的輸入流對(duì)象被其他模塊 close 掉了，導(dǎo)致 UC 使用的時(shí)候發(fā)現(xiàn) FD 對(duì)象已經(jīng)被關(guān)閉，從而做了崩潰處理。最后的處理方案就變成了用戶解決其他模塊的誤關(guān) FD 的問題。

上述就是小編為大家分享的mPaaS框架下是怎么使用Crash SDK對(duì)閃退進(jìn)行分析了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。