Application Not Responding
1. 產(chǎn)生的原因
主線程任務(wù)執(zhí)行時間過長(阻塞), 系統(tǒng)消息得不到響應(yīng);
- app自身進(jìn)程主線程阻塞, 掛起, 死鎖導(dǎo)致
- 機(jī)器本身的cpu, 內(nèi)存, io繁忙, 無法及時響應(yīng)
根本原因還是在系統(tǒng)消息得不到響應(yīng)造成的,盜用2張圖來說明一下
anr_reason_1.png
anr_reason_2.png
類型
| Type | Method call | Log sample | time out |
|---|---|---|---|
| Input dispatch | onClick(),onTouch(),onKeydown(),onKeyup()…… | Input dispatching timed out | 8 |
| Broadcast | onReceive() | Timeout of broadcast | FG: 10, BG 60 |
| Service | onBind(),onCreate(),onStartCommand(),onUnbind(),onDestroy() | Timeout executing service | FG: 20, BG 200 |
2. trace分析
- 基本結(jié)構(gòu)
// 線程名稱, 線程優(yōu)先級, 線程id, 線程狀態(tài)
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x74960ee8 self=0xb83b52f0
| sysTid=30752 nice=0 cgrp=default sched=0/0 handle=0xb6fcbbec
| state=S schedstat=( 32407519095 10037462519 57602 ) utm=2867 stm=373 core=0 HZ=100
| stack=0xbe26e000-0xbe270000 stackSize=8MB
| held mutexes=
一般從主線程看起, 確定主線程的狀態(tài), 線程的狀態(tài)可以看線程的基礎(chǔ)
anr_trace_1.png
2.1 死鎖
DALVIK THREADS (87):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x74960ee8 self=0xb83b52f0
| sysTid=30752 nice=0 cgrp=default sched=0/0 handle=0xb6fcbbec
| state=S schedstat=( 32407519095 10037462519 57602 ) utm=2867 stm=373 core=0 HZ=100
| stack=0xbe26e000-0xbe270000 stackSize=8MB
| held mutexes=
at com.eebbk.bfc.sdk.download.DownloadQueue.add(DownloadQueue.java:97)
// 等待鎖, lock的一個對象的,一般都是synchronized關(guān)鍵字的對象鎖; 被id=87的線程持有
- waiting to lock <0x0464a122> (a com.eebbk.bfc.sdk.download.DownloadQueue) held by thread 87
at com.eebbk.bfc.sdk.download.DownloadManager.start(DownloadManager.java:195)
at com.eebbk.bfc.sdk.download.services.DownloadServiceStub.start(DownloadServiceStub.java:76)
at com.eebbk.bfc.sdk.download.BfcDownload.startTask(BfcDownload.java:219)
at com.eebbk.bfc.sdk.downloadmanager.DownloadController.addTask(DownloadController.java:246)
at com.eebbk.commonutils.download.DownLoadUtils.buildTask(DownLoadUtils.java:61)
at com.eebbk.view.DownLoadStateView.openFile(DownLoadStateView.java:937)
at com.eebbk.view.DownLoadStateView.access$1200(DownLoadStateView.java:60)
...
"pool-5-thread-4" prio=5 tid=87 Blocked
| group="main" sCount=1 dsCount=0 obj=0x1364efa0 self=0xb8ad5f20
| sysTid=11171 nice=10 cgrp=bg_non_interactive sched=0/0 handle=0xb8d97f20
| state=S schedstat=( 8278520740 14167294365 95936 ) utm=423 stm=404 core=2 HZ=100
| stack=0x9ca87000-0x9ca89000 stackSize=1036KB
| held mutexes=
at com.eebbk.bfc.sdk.download.DownloadManager.isDownloadManagerIdle(DownloadManager.java:723)
// 等待一個鎖, 該鎖被tid=1的線程持有
- waiting to lock <0x14a3e865> (a com.eebbk.bfc.sdk.download.DownloadManager) held by thread 1
at com.eebbk.bfc.sdk.download.services.DownloadServiceStub.stopServiceDelayedIfIdle(DownloadServiceStub.java:223)
at com.eebbk.bfc.sdk.download.services.DownloadServiceStub.onDownloadManagerIdle(DownloadServiceStub.java:177)
at com.eebbk.bfc.sdk.download.DownloadManager.downloadQueueIdle(DownloadManager.java:713)
at com.eebbk.bfc.sdk.download.DownloadQueue.scheduleNext(DownloadQueue.java:270)
// 已經(jīng)持有一個鎖, 該鎖被tid=1的線程等待
- locked <0x0464a122> (a com.eebbk.bfc.sdk.download.DownloadQueue)
at com.eebbk.bfc.sdk.download.DownloadQueue.taskFinished(DownloadQueue.java:200)
at com.eebbk.bfc.sdk.download.DownloadManager.onRunnableFinished(DownloadManager.java:640)
死鎖基本上是最好分析的ANR了, main thread狀態(tài)是block的, 等待一個鎖, 可以找到持有該鎖的線程id, 通過鎖對象也可以搜索到; 然后找到持有該鎖的線程狀態(tài), 對應(yīng)解決;
trace文件可以看出程序運(yùn)行的流程, 不過由于dump內(nèi)存順序, 代碼的調(diào)用順序是從后向前的;
ANR的trace文件獲取
1. 保存位置
- /data/anr/traces.txt 最近一次anr的信息
- /data/system/dropbox 發(fā)生的嚴(yán)重問題的信息
2. DropBoxManager
DropBoxManager是系統(tǒng)用于記錄運(yùn)行過程中, 內(nèi)核, 系統(tǒng)進(jìn)程, 用戶進(jìn)程等出現(xiàn)嚴(yán)重問題時的log;
可以通過監(jiān)聽DropBoxManager.ACTION_DROPBOX_ENTRY_ADDED廣播, 在發(fā)生異常時, 獲取數(shù)據(jù);
2.1 記錄log的類型
- Crash
應(yīng)用程序遇到異常,被強(qiáng)制關(guān)閉時的log - ANR
- WTF
Log.wtf()方法產(chǎn)生的數(shù)據(jù) - strict_mode (StrictMode)
嚴(yán)苛模式產(chǎn)生的異常
