android dropbox anr分析,Android如何分析排查ANR

釋放雙眼，帶上耳機，聽聽看~！

在Android開發中，當程式發生異常時會抛出異常資訊，先說下三種常見類型：

清單内容KeyDispatchTimeout(谷歌default 5s，MTK平台上是8s) –主要類型

按鍵或觸摸事件在特定時間内無響應

BroadcastTimeout(10s)

BroadcastReceiver在特定時間内無法處理完成

ServiceTimeout(20s) –小機率類型

Service在特定的時間内無法處理完成

一些典型的ANR 問題場景

1)最常見錯誤，UI線程等待其它線程釋放某個鎖，導緻UI線程無法處理使用者輸入；

2)遊戲中每幀動畫都進行了比較耗時的大量計算，導緻CPU忙不過來；

3)Web應用中，網絡狀态不穩定，而界面在等待網絡資料；

4)UI線程中進行了一些磁盤IO(包括資料庫、SD卡等等)的操作，在個别裝置上因為硬體損壞等原因阻塞住了；

5)手機被其他App占用着CPU，自己擷取不到足夠的CPU 時間片，純屬誤傷。

排查分析的思路：

1、通過ANR 日志定位問題

當ANR發生時，我們往往通過Logcat和traces檔案(目錄/data/anr/)的相關資訊輸出去定位問題。主要包含以下幾方面：

1)基本資訊，包括程序名、程序号、包名、系統build号、ANR 類型等等；

2)CPU使用資訊，包括活躍程序的CPU 平均占用率、IO情況等等；

3)線程堆棧資訊，所屬程序包括發生ANR的程序、其父程序、最近有活動的3個程序等等。

1.1首先通過Log來擷取異常資訊

android系統會自動幫我們生成一個log日志輸出檔案，在data/system/dropbox/下，真機測試需要root權限，模拟器在DDMS下可以檢視。

用這種方法，出現問題，根本不需要斷點調試 ， 直接定位到問題，屢試不爽 。

從LOG可以看出ANR的類型，CPU的使用情況，

一般在如下幾種情況會産生log 。

1，程式異常退出 ， uncaused exception

2，程式強制關閉 ，Force Closed (簡稱FC)

3，程式無響應 ， Application No Response (簡稱ANR) ， 順便，一般主線程超過5秒麼有處理就會ANR

步驟：

1.打開log檔案 ， 由于是ANR錯誤，是以搜尋”ANR ” ， 為何要加空格呢，你加上和去掉比較一下就知道了 。 可以屏蔽掉不少儲存到anr.log檔案的無效資訊

定位到關鍵的事件資訊如下：

01-15 16:49:02.433 E/ActivityManager( 2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)

01-15 16:49:02.433 E/ActivityManager( 2466): Reason: keyDispatchingTimedOut

01-15 16:49:02.433 E/ActivityManager( 2466): Load: 0.6 / 0.61 / 0.42

01-15 16:49:02.433 E/ActivityManager( 2466): CPU usage from 1337225ms to 57ms ago:

01-15 16:49:02.433 E/ActivityManager( 2466): sensorserver_ya: 8% = 0% user + 8% kernel / faults: 40 minor

......

01-15 16:49:02.433 E/ActivityManager( 2466): -com.android.mms: 0% = 0% user + 0% kernel

01-15 16:49:02.433 E/ActivityManager( 2466): -flush-179:8: 0% = 0% user + 0% kernel

01-15 16:49:02.433 E/ActivityManager( 2466): TOTAL: 25% = 10% user + 14% kernel + 0% iowait + 0% irq + 0% softirq

01-15 16:49:02.436 I/ ( 2466): dumpmesg > "/data/log/dumpstate_app_anr.log"

我們用自然語言來描述一下日志，

01-15 16:49:02.433 E/ActivityManager( 2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)

翻譯：在16:49分2秒433毫秒的時候 ActivityManager (程序号為2466) 發生了如下錯誤：com.android.mms包下面的.ui.SlideshowActivity 無響應 。

01-15 16:49:02.433 E/ActivityManager( 2466): Reason: keyDispatchingTimedOut

翻譯：原因 ， keyDispatchingTimeOut – 按鍵配置設定逾時

01-15 16:49:02.433 E/ActivityManager( 2466): Load: 0.6 / 0.61 / 0.42

翻譯：5分鐘，10分鐘，15分鐘内的平均負載分别為：0.6 , 0.61 , 0.42

我們大概知道問題是什麼了，問題是在點選按鈕某時候可能處理不過來按鈕事件，導緻逾時無響應 。但我們不能準确的知道到底問題在哪兒 ， 隻是猜測 ，比如這個應用程式中，多個IO操作的地方都在主線程中，可能引起問題，但不好判斷到底是哪個 ，是以我們目前掌握的資訊還不夠 。

于是我們再分析虛拟機資訊 ，搜尋“Dalvik Thread”關鍵詞，快速定位到本應用程式的虛拟機資訊日志

1.2通過分析trace檔案得到ANR資訊(真機導出，模拟機在DDMS下檢視)

如果ANR發生，對應的應用會收到SIGQUIT異常終止信号，dalvik虛拟機就會自動在/data/anr/目錄下生成trace.txt檔案，将異常資訊寫入到traces檔案中，系統會記錄異常的位置、CPU和記憶體當時的使用情況，通過檢視日志基本就能判斷問題所在。

接下來用adb shell指令導出該檔案，通過shell指令就可以了。

adb pull /data/anr/traces.txt d:/ =》意思是将手機上的traces.txt導出到電腦的d目錄下

或者

1、adb shell

2、cat /data/anr/xxx >/mnt/sdcard/yy/zz.txt

3、exit

4、adb pull /mnt/sdcard/yy/zz.txt d: ,即可将檔案導出到了d盤。

在發生ANR時，

步驟：

1. 找到ANR關鍵字(大寫比對)

2. 向上查找timeout關鍵字，這個時候能找到ANR的原因，如： Application do too much work in main thread 等。

3. 檢視trace 檔案找出出現的最終原因。

測試過程發現ANR的現狀

1、在平常測試中，ANR基本測試不到，因為ANR基本發生在垃圾裝置中，弱網絡，頻繁操作。

2、問題不必現，即使看到了問題，定位麻煩：要去data/anr.txt 檔案裡面查找。必須root,沒有對應關系，分析複雜，導出檔案就必須依賴手機零距離。

由于anr問題不必現，是以引入以下ANR檢測工具，當anr問題出現時，自動dump手機中的日志資訊如trace檔案、堆棧資訊

基本原理

檢測到UI主線程卡頓時間超過設定的時間，如4s，即dump trace檔案以及堆棧資訊，同時抛出異常，收集資訊，根據這些檔案資訊即可定位到發生anr的原因

1.3在源代碼中插入ANR檢測工具(BlockCanary、StrictMode)

1.4使用第三方SDK輸出Crach資訊到背景伺服器：

如騰訊bugly 和umeng