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

在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

總結

以上是生活随笔為你收集整理的android dropbox anr分析,Android如何分析排查ANR的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。