ANR檢查定位分析工具

百度MTC是業(yè)界領(lǐng)先的移動(dòng)應(yīng)用測(cè)試服務(wù)平臺(tái)，為廣大開發(fā)者在移動(dòng)應(yīng)用測(cè)試中面臨的成本、技術(shù)和效率問題提供解決方案。同時(shí)分享行業(yè)領(lǐng)先的百度技術(shù)，作者來自百度員工和業(yè)界領(lǐng)袖等。

一、ANR是什么

簡(jiǎn)單說，通常就是App運(yùn)行的時(shí)候，duang~卡住了，怎么搞都動(dòng)不了。當(dāng)卡住超過一定時(shí)間，Android系統(tǒng)認(rèn)為這就是一次“ANR（Application Not Responding）”。

具體說，在以下情況發(fā)生時(shí)，會(huì)發(fā)生ANR（可能在不同ROM中時(shí)間有所更改）：

• 用戶的輸入在5s內(nèi)沒被App響應(yīng)；

• BroadcastReceiver的onReceiver()超過10s；

• Service中各生命周期函數(shù)執(zhí)行超過20s。

二、ANR必須死

用戶在App的絕大部分操作，都需要有App的主動(dòng)回應(yīng)，比如按下按鈕之后按鈕樣式的改變、下拉滾動(dòng)條內(nèi)容的移動(dòng)、加載資源時(shí)的進(jìn)度條轉(zhuǎn)轉(zhuǎn)轉(zhuǎn)，它們都是“操作-反饋”配對(duì)的模式。對(duì)于我們手機(jī)上最常見的觸摸操作，0.1s的響應(yīng)延遲已經(jīng)有很明顯的卡頓感了。而對(duì)于常見的ANR，用戶至少要等5s以上！

發(fā)生了ANR，往往會(huì)彈出對(duì)話框，問用戶是繼續(xù)等待還是直接關(guān)掉：

相信幾乎所有Android手機(jī)用戶都見過這個(gè)然并卵的ANR對(duì)話框，但大部分普通用戶根本不知道這個(gè)對(duì)話框在講什么，并且往往也只有關(guān)閉App。漫長(zhǎng)的等待就給我看這個(gè)？從用戶的體驗(yàn)看，就是心中一萬只草泥馬奔騰起來撞火車的感受。可見ANR對(duì)于應(yīng)用的影響并不亞于Crash。

一般來說，界面相對(duì)越不“流暢”的App（說明UI線程耗時(shí)操作多）越容易發(fā)生ANR（一個(gè)輸入事件在某個(gè)設(shè)備A上4秒有了反饋，并不意味著它在其他設(shè)備B上是安全的）。ANR其實(shí)就是界面卡頓的極端情況。反過來，只要通過合理的方案消滅了App出現(xiàn)的ANR，往往也同時(shí)會(huì)使App展示界面表現(xiàn)會(huì)更加順滑流暢。

一些典型的ANR問題場(chǎng)景

1）最常見的錯(cuò)誤，UI線程等待其它線程釋放某個(gè)鎖，導(dǎo)致UI線程無法處理用戶輸入；

2）游戲中每幀動(dòng)畫都進(jìn)行了比較耗時(shí)的大量計(jì)算，導(dǎo)致CPU忙不過來；

3）Web應(yīng)用中，網(wǎng)絡(luò)狀態(tài)不穩(wěn)定，而界面在等待網(wǎng)絡(luò)數(shù)據(jù)；

4）UI線程中進(jìn)行了一些磁盤IO（包括數(shù)據(jù)庫、SD卡等等）的操作，在個(gè)別設(shè)備上因?yàn)橛布p壞等原因阻塞住了；

5）手機(jī)被其他App占用著CPU，自己獲取不到足夠的CPU時(shí)間片，純屬誤傷。

通過ANR日志定位問題

當(dāng)ANR發(fā)生時(shí)，我們往往通過Logcat和traces文件（目錄/data/anr/）的相關(guān)信息輸出去定位問題。主要包含以下幾方面：

1）基本信息，包括進(jìn)程名、進(jìn)程號(hào)、包名、系統(tǒng)build號(hào)、ANR類型等等；

2）CPU使用信息，包括活躍進(jìn)程的CPU平均占用率、IO情況等等；

3）線程堆棧信息，所屬進(jìn)程包括發(fā)生ANR的進(jìn)程、其父進(jìn)程、最近有活動(dòng)的3個(gè)進(jìn)程等等。

三、測(cè)試過程發(fā)現(xiàn)ANR的現(xiàn)狀

1、在平常測(cè)試中，ANR有基本測(cè)試不到，因?yàn)?/span>ANR基本發(fā)生在垃圾設(shè)備中，弱網(wǎng)絡(luò)，頻繁操作。

2、問題不必現(xiàn)，即使看到了問題，定位麻煩：要去data/anr.txt文件里面查找。必須root,沒有對(duì)應(yīng)關(guān)系，分析復(fù)雜，導(dǎo)出文件就必須依賴手機(jī)零距離。

四、引入ANR檢測(cè)工具

由于anr問題不必現(xiàn)，因此引入以下ANR檢測(cè)工具，當(dāng)anr問題出現(xiàn)時(shí)，自動(dòng)dump手機(jī)中的日志信息如trace文件、堆棧信息等，基本原理如下：

4.1、基本原理

         檢測(cè)到UI主線程卡頓時(shí)間超過設(shè)定的時(shí)間，如4s，即dump trace文件以及堆棧信息，同時(shí)拋出異常，收集信息，根據(jù)這些文件信息即可定位到發(fā)生anr的原因

4.2、ANR檢測(cè)工具在Baidu Browser中的應(yīng)用

4.2.1如何在源代碼中插入anr檢測(cè)工具

步驟一：源代碼libs中添加anr.jar

步驟二：在 Application 的onCreate中添加初始化sdk的代碼

initSDK(Context context, String appKey, boolean watchdog, int time)

其中time表示檢測(cè)判定線程是否超時(shí)（發(fā)生anr）的門限值，單位：ms

步驟三：正常編譯打包apk

4.2.2如何測(cè)試發(fā)現(xiàn)并定位anr問題

• 安裝步驟4.2.1編譯打包插入anr檢測(cè)的apk

• 測(cè)試app，任意操作（monkey/case），當(dāng)發(fā)生anr時(shí)，會(huì)自動(dòng)殺掉進(jìn)程，并在本地生成日志文件日志路徑：/sdcard/lynq_anr下有兩個(gè)文件夾

以Baidu Browser啟動(dòng)為例。

Baidu Browser啟動(dòng)過程主線程過長(zhǎng)，在低端機(jī)上容易導(dǎo)致發(fā)生anr；線程超時(shí)，app進(jìn)程kill掉，查看手機(jī)本地trace日志，Crash信息包括trace文件以及堆棧信息

• 分析trace文件

Trace文件通過eclipse中的DDMS可以查看具體發(fā)生ANR卡頓的原因

通過real Time/Call從大到小排序，找到對(duì)應(yīng)的與代碼相關(guān)消耗時(shí)間最大的方法

可以看出書簽數(shù)據(jù)庫初始化消耗CPU時(shí)間最長(zhǎng)。

• 查看耗時(shí)最長(zhǎng)方法對(duì)應(yīng)的源代碼

找到對(duì)應(yīng)的源代碼如下：

主要是數(shù)據(jù)庫的初始化在啟動(dòng)的主線程中進(jìn)行，容易導(dǎo)致超時(shí)在低端機(jī)上發(fā)生anr問題。

更多干貨分享請(qǐng)關(guān)注”百度MTC學(xué)院“http://mtc.baidu.com/academy/article