簡介：Android Native crash 處理案例分享

1. 背景

目前 mPaas[1] Android使用Crash SDK對閃退進行的處理，CrashSDK 是 Android 平臺上一款功能強大的崩潰日志收集 SDK，有著極高的崩潰收集率和完整、全面的崩潰日志信息，生成的日志內(nèi)容非常利于問題的跟進和解決。在日常運維中，經(jīng)常遇到一些閃退，無法直接從閃退堆棧找到原因，尤其是一些非Java的Native的閃退，這里分享下在mPaas框架下怎么使用Crash SDK分析閃退。

2. 閃退報文分析工具介紹

對于mPaas的用戶，從MAS上閃退分析平臺導出的一般是原始的閃退信息，閃退信息比較多，如果直接閱讀會比較困難，使用者可以通過下載Chrome的插件LogAnalyzer，LogAnalyzer會將Crash SDK生成的日志文本內(nèi)容轉化成可視效果較強的 HTML 頁面展現(xiàn)，功能強大，主要包含：
1) 高亮顯示日志中重點信息，并使用不同顏色區(qū)分；
2) 支持日志內(nèi)容整體結構預覽，快速定位重點內(nèi)容；
3) 常見崩潰原因提醒；
安裝好chrome插件后，仍需以下配置：

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

由于MAS默認下載的文件后綴是.dat，需改為.txt，否則 LogAnalyzer 無法識別。

2. 修改插件配置

由于 Chrome 默認權限限制，任何 Chrome 插件均默認無法訪問文件網(wǎng)址，需要在 Chrome 插件中進行如下操作。
1) 打開 Chrome 插件管理頁面 chrome://extensions/
2) 找到 LogAnalyzer 插件，點擊 “詳細信息" 進入設置：

3) 勾選“允許訪問文件網(wǎng)址”選項
4) 打開或者刷新日志頁面，LogAnalyzer 便可生效。

3. 生效效果

把日志文件直接拖到chrome后，可以看到右邊插件生效后，可以通過不同顏色顯示閃退信息的各個字段
首次打開后的使用說明如下：

正常查看閃退截圖如下：

3. 閃退分析舉例

我們經(jīng)常在日常運維中遇到一些非Java的Native模塊閃退，比如UC。其實很多場景下，閃退的根因并不是UC，只是最后的閃退點在UC。以日常運維高頻的UC內(nèi)核的閃退為例，對一些案例的處理分享如下。

1. java空指針導致UC閃退

在閃退點上可以看到以下閃退信息（已經(jīng)隱藏客戶apk相關信息)，暫無任何線索，繼續(xù)查看日志。

查看logcat節(jié)點信息時，首先看到關鍵字：begin to generate native report, 表示當前是閃退日志上報的日志，在往前看，logcat節(jié)點里打印了異常堆棧信息，從堆棧信息可以看到，由于precreate操作觸發(fā)了底層的空指針，從而導致初始化異常，觸發(fā)了閃退。解決方案為臨時關閉預創(chuàng)建，從而規(guī)避閃退。

從上面的案例可以看出，
1) Native的閃退原因不一定是Native模塊，有可能是java異常導致的。
2) begin to generate native report 附近可以查看閃退相關的logcat信息，協(xié)助定位閃退的上下文日志。

2. 上層OOM導致UC閃退

首先，查看上報的閃退點的日志，如下圖所示，閃退在RenderThread里，毫無頭緒。

其次，在logcat節(jié)點里查找begin to generate native report上報節(jié)點，可以看到大量的底層OOM的異常日志，基本確定是OOM的原因了，繼續(xù)查找OOM的觸發(fā)源頭。

點擊閃退里的內(nèi)存節(jié)點，基本原因就比較清晰了，當前手機的vmsize基本已經(jīng)到最大了，我們知道對于 32 位的進程，APP 可使用的 VmSize 最大為 3GB，不過當運行在 64 位 CPU 上時，VmSize 最大可超過 3GB，接近 4GB。但是由于內(nèi)核需要占據(jù)一部分，以及不同的ROM版本的差別，有以下規(guī)律：android 8.1.0 及之后的系統(tǒng)，大部分 native oom crash 發(fā)生時 vmSize 分布在 3.5 - 3.9 G 的位置，相對較為集中。下面講解下如何解決OOM。

3. FD誤關導致UC閃退

日志如下圖所示，我大概只能看出SIGILL有可能是主動崩潰，崩潰ILL_ILLOPC表示非法操作。

然后我們繼續(xù)看logcat節(jié)點的begin to generate native report, 基本確認原因是為uc使用的FD對象被其他程序關閉。

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

4. 總結

綜合以上的case分析，在遇到Native模塊閃退的時候，一般如果從直接的閃退堆棧看不出原因的時候，不要心急，可以搜索begin to generate native report 找到崩潰上下文，多看看logcat閃退上下文的日志，會有一些收獲，同時對于oom類型的問題，可以結合當前內(nèi)存統(tǒng)計來看。

我們是阿里云智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業(yè)務系統(tǒng)高可用的工程師團隊；提供專業(yè)、體系化的SRE服務，幫助廣大客戶更好地使用云、基于云構建更加穩(wěn)定可靠的業(yè)務系統(tǒng)，提升業(yè)務穩(wěn)定性。我們期望能夠分享更多幫助企業(yè)客戶上云、用好云，讓客戶云上業(yè)務運行更加穩(wěn)定可靠的技術。

原文鏈接：https://developer.aliyun.com/article/781273?

版權聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內(nèi)容。

總結

以上是生活随笔為你收集整理的Android Native crash 处理案例分享的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。