百度MTC是業界領先的移動應用測試服務平台，為廣大開發者在移動應用測試中面臨的成本、技術和效率問題提供解決方案。同時分享行業領先的百度技術，作者來自百度員工和業界領袖等。
一、ANR是什麼
簡單說，通常就是App運作的時候，duang~卡住了，怎麼搞都動不了。當卡住超過一定時間，Android系統認為這就是一次“ANR（Application Not Responding）”。
具體說，在以下情況發生時，會發生ANR（可能在不同ROM 中時間有所更改）：
- 使用者的輸入在5s内沒被App響應；
- BroadcastReceiver的onReceiver()超過10s；
- Service中各生命周期函數執行超過20s。
二、ANR必須死
使用者在App的絕大部分操作，都需要有App的主動回應，比如按下按鈕之後按鈕樣式的改變、下拉滾動條内容的移動、加載資源時的進度條轉轉轉，它們都是“操作-回報”配對的模式。對于我們手機上最常見的觸摸操作，0.1s的響應延遲已經有很明顯的卡頓感了。而對于常見的ANR，使用者至少要等5s以上！
發生了ANR，往往會彈出對話框，問使用者是繼續等待還是直接關掉：
相信幾乎所有Android手機使用者都見過這個然并卵的ANR對話框，但大部分普通使用者根本不知道這個對話框在講什麼，并且往往也隻有關閉App。漫長的等待就給我看這個？從使用者的體驗看，就是心中一萬隻草泥馬奔騰起來撞火車的感受。可見ANR對于應用的影響并不亞于Crash。
一般來說，界面相對越不“流暢”的App（說明UI線程耗時操作多）越容易發生ANR（一個輸入事件在某個裝置A上4秒有了回報，并不意味着它在其他裝置B上是安全的）。ANR其實就是界面卡頓的極端情況。反過來，隻要通過合理的方案消滅了App出現的ANR，往往也同時會使App展示界面表現會更加順滑流暢。
一些典型的ANR 問題場景
1）最常見的錯誤，UI線程等待其它線程釋放某個鎖，導緻UI線程無法處理使用者輸入；
2）遊戲中每幀動畫都進行了比較耗時的大量計算，導緻CPU忙不過來；
3）Web應用中，網絡狀态不穩定，而界面在等待網絡資料；
4）UI線程中進行了一些磁盤IO（包括資料庫、SD卡等等）的操作，在個别裝置上因為硬體損壞等原因阻塞住了；
5）手機被其他App占用着CPU，自己擷取不到足夠的CPU 時間片，純屬誤傷。
通過ANR 日志定位問題
當ANR發生時，我們往往通過Logcat和traces檔案（目錄/data/anr/）的相關資訊輸出去定位問題。主要包含以下幾方面：
1）基本資訊，包括程序名、程序号、包名、系統build号、ANR 類型等等；
2）CPU使用資訊，包括活躍程序的CPU 平均占用率、IO情況等等；
3）線程堆棧資訊，所屬程序包括發生ANR的程序、其父程序、最近有活動的3個程序等等。
三、測試過程發現ANR的現狀
1、在平常測試中，ANR有基本測試不到，因為ANR基本發生在垃圾裝置中，弱網絡，頻繁操作。
2、問題不必現，即使看到了問題，定位麻煩：要去data/anr.txt 檔案裡面查找。必須root,沒有對應關系，分析複雜，導出檔案就必須依賴手機零距離。
四、引入ANR檢測工具
由于anr問題不必現，是以引入以下ANR檢測工具，當anr問題出現時，自動dump手機中的日志資訊如trace檔案、堆棧資訊等，基本原理如下：
4.1、基本原理
檢測到UI主線程卡頓時間超過設定的時間，如4s，即dump trace檔案以及堆棧資訊，同時抛出異常，收集資訊，根據這些檔案資訊即可定位到發生anr的原因
4.2、ANR檢測工具在Baidu Browser中的應用
4.2.1如何在源代碼中插入anr檢測工具
步驟一：源代碼libs中添加anr.jar
步驟二：在 Application 的onCreate中添加初始化sdk的代碼
initSDK(Context context, String appKey, boolean watchdog, int time)
其中time表示檢測判定線程是否逾時（發生anr）的門限值，機關：ms
步驟三：正常編譯打包apk
4.2.2如何測試發現并定位anr問題
Ø 安裝步驟4.2.1編譯打包插入anr檢測的apk
Ø 測試app，任意操作（monkey/case），當發生anr時，會自動殺掉程序，并在本地生成日志檔案日志路徑：/sdcard/lynq_anr下有兩個檔案夾
以Baidu Browser啟動為例。
Baidu Browser啟動過程主線程過長，在低端機上容易導緻發生anr；線程逾時，app程序kill掉，檢視手機本地trace日志， Crash資訊包括trace檔案以及堆棧資訊
Ø 分析trace檔案
Trace檔案通過eclipse中的DDMS可以檢視具體發生ANR卡頓的原因
通過real Time/Call從大到小排序，找到對應的與代碼相關消耗時間最大的方法
可以看出
書簽資料庫初始化消耗CPU時間最長。
Ø 檢視耗時最長方法對應的源代碼
找到對應的源代碼如下：
主要是資料庫的初始化在啟動的主線程中進行，容易導緻逾時在低端機上發生anr問題。
更多幹貨分享請關注”百度MTC學院“http://mtc.baidu.com/academy/article