1 為什么會(huì)產(chǎn)生ANR

在Android里, App的響應(yīng)能力是由Activity Manager和Window Manager系統(tǒng)服務(wù)來監(jiān)控的. 通常在如下三種情況下會(huì)彈出ANR對話框:

1：5s內(nèi)無法響應(yīng)用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等)
2：BroadcastReceiver在10s內(nèi)無法結(jié)束
3：ServiceTimeout(20s) --小概率類型型酥，Service在特定的時(shí)間內(nèi)無法處理完成

造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時(shí)操作, 例如文件讀寫, 數(shù)據(jù)庫讀寫, 網(wǎng)絡(luò)查詢等.

2 ANR分析

2.1 獲取ANR產(chǎn)生的trace文件

ANR產(chǎn)生時(shí), 系統(tǒng)會(huì)生成一個(gè)traces.txt的文件放在/data/anr/下. 可以通過[adb]命令將其導(dǎo)出到本地:

$adb pull data/anr/traces.txt .

本例中問題出現(xiàn)在MainActivity.java 27行腔召，因?yàn)檫@里調(diào)用了Thread.sleep方法携御。

----- pid 30307 at 2018-09-06 14:51:14 -----
Cmd line: com.example.android

JNI: CheckJNI is off; workarounds are off; pins=0; globals=272

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)

"main" prio=5 tid=1 TIMED_WAIT
  | group="main" sCount=1 dsCount=0 obj=0x416eaf18 self=0x416d8650
  | sysTid=30307 nice=0 sched=0/0 cgrp=apps handle=1074565528
  | state=S schedstat=( 0 0 0 ) utm=5 stm=4 core=3
  | stack=0x7fdc4ca000-0x7fdc4cc000 stackSize=8MB
  | held mutexes=
  at java.lang.VMThread.sleep(Native Method)
  at java.lang.Thread.sleep(Thread.java:1044)
  at java.lang.Thread.sleep(Thread.java:1026)
  at com.example.android.MainActivity$1.run(MainActivity.java:27)
  at android.app.Activity.runOnUiThread(Activity.java:4794)
  at com.example.android.MainActivity.onResume(MainActivity.java:33)
  at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1282)
  at android.app.Activity.performResume(Activity.java:5405)

從第一行開始我們來按每一行解析其所代表的含義也殖。

1，代表 PID at time
2腋颠，Cmd line: process name
3繁成，固定頭，指明下面都是當(dāng)前運(yùn)行的dvm thread 淑玫，“DALVIK THREADS:” 及所包含的線程數(shù)
4巾腕，"main" prio=5 tid=1 Native
分別代表thread name, java thread Priority, DVM thread id, DVM thread status
"main" :main thread -> activity thread
prio :java thread priority default is 5, （正常區(qū)域是1-10）
tid:是DVM thread id, 不是 linux thread id（下一行的sysTid才是）
Native:DVM thread Status 正常有這些狀態(tài)（ZOMBIE, RUNNABLE, TIMED_WAIT, MONITOR, WAIT, INITALIZING,STARTING, NATIVE, VMWAIT, SUSPENDED,UNKNOWN）
5，group="main" sCount=1 dsCount=0 obj=0x416eaf18 self=0x416d8650
代表 DVM thread status絮蒿。
group:是線程所處的線程組 default is “main”
sCount: 線程被正常掛起的次數(shù) 1 (thread suspend count)
dsCount: 線程因調(diào)試而掛起次數(shù) 0 (thread dbg suspend count)
obj: 當(dāng)前線程所關(guān)聯(lián)的java線程對象 0x75720fb8 (thread obj address)
Sef: 該線程本身的地址 0x7f7e8af800 (thread point address)
6尊搬，sysTid=30307 nice=0 sched=0/0 cgrp=apps handle=1074565528
代表Linux thread status顯示線程調(diào)度信息
sysTId: linux系統(tǒng)下得本地線程id linux thread tid
Nice:線程的調(diào)度有優(yōu)先級 linux thread nice value
cgrp: 優(yōu)先組屬 c group
sched: 調(diào)度策略 cgroup policy/gourp id
handle: 處理函數(shù)地址 handle address
7，state=S schedstat=( 0 0 0 ) utm=5 stm=4 core=3
代表CPU Sched stat 顯示更多該線程當(dāng)前上下文
State:調(diào)度狀態(tài) process/thread state （正常有 "R (running)", "S (sleeping)", "D (disk sleep)", "T (stopped)", "t (tracing stop)", "Z (zombie)", "X (dead)", "x (dead)", "K (wakekill)", "W (waking)",）土涝，通常一般的Process 處于的狀態(tài)都是S (sleeping), 而如果一旦發(fā)現(xiàn)處于如D (disk sleep), T (stopped), Z (zombie) 等就要認(rèn)真審查.
Schedstat (Run CPU Clock/ns, Wait CPU Clock/ns, Slice times) 該線程運(yùn)行信息
utm: utime, user space time 線程用戶態(tài)下使用的時(shí)間值(單位是jiffies）
stm: stime, kernel space time 內(nèi)核態(tài)下得調(diào)度時(shí)間值
core: now running in cpu. 最后運(yùn)行改線程的cup標(biāo)識
8毁嗦，stack=0x7f7dc93000-0x7f7dc95000 stackSize=1020KB
代表堆棧地址區(qū)域及size
9，held mutexes=
代表是否被鎖住回铛，正常有四個(gè)屬性(mutexes: tll=0 tsl=0 tscl=0 ghl=0)狗准，0表示unlock，其它值都代表被lock茵肃，
tll: thread List Lock,
tsl: thread Suspend Lock,
tscl: thread Suspend Count Lock
ghl: gc Heap Lock
10腔长，剩余的就是一些 Call Stack

2.2 CPU負(fù)荷和CPU使用率

//CPU前一分鐘、五分鐘验残、十五分鐘的CPU平均負(fù)載, 
//CPU平均負(fù)載可以理解為一段時(shí)間內(nèi)正在使用和等待使用CPU的活動(dòng)進(jìn)程的平均數(shù)量捞附。
    Load: 5.16 / 9.69 / 30.66      
//ago，表示ANR發(fā)生之前的一段時(shí)間內(nèi)的CPU使用率，并不是某一時(shí)刻的值
    CPU usage from 34388ms to -1ms ago:
    4.1% 32614/com.qihoo.browser: 2.5% user + 1.6% kernel / faults: 465 minor 1 major
    3% 379/adbd: 0.2% user + 2.8% kernel / faults: 1653 minor
    2.6% 743/system_server: 1.8% user + 0.7% kernel / faults: 689 minor
    2.5% 2326/com.qihoo.daemon: 2.2% user + 0.2% kernel / faults: 601 minor
    2.4% 1009/RX_Thread: 0% user + 2.4% kernel
    2% 280/surfaceflinger: 1.2% user + 0.8% kernel / faults: 1361 minor
    1.8% 2675/com.lbe.security:service: 1.7% user + 0.1% kernel / faults: 749 minor
    .......
    +0% 3682/migration/1: 0% user + 0% kernel
    +0% 3683/kworker/1:0: 0% user + 0% kernel
    +0% 3684/ksoftirqd/1: 0% user + 0% kernel
    9.7% TOTAL: 4.8% user + 4.2% kernel + 0.3% iowait + 0.3% softirq
//later鸟召，表示ANR發(fā)生之后
    CPU usage from 1656ms to 2187ms later:
    8.7% 743/system_server: 0% user + 8.7% kernel / faults: 4 minor
    7% 943/InputDispatcher: 0% user + 7% kernel
    1.7% 1199/Binder_6: 0% user + 1.7% kernel
    5.2% 379/adbd: 0% user + 5.2% kernel / faults: 27 minor
    3.5% 379/adbd: 0% user + 3.5% kernel
    1.7% 1009/RX_Thread: 0% user + 1.7% kernel
    1.7% 1768/mpdecision: 0% user + 1.7% kernel
    1.7% 1784/mpdecision: 0% user + 1.7% kernel
    1.2% 6883/kworker/u:37: 0% user + 1.2% kernel
    1.3% 29165/kworker/0:2: 0% user + 1.3% kernel
    2.3% TOTAL: 0.1% user + 0.3% kernel + 1.8% iowait

如果說某個(gè)進(jìn)程在ANR發(fā)生時(shí)CPU使用率出現(xiàn)很高的情況胆绊，那么就可以知道這個(gè)進(jìn)程在做非常消耗CPU的事情，一般這種情況下這個(gè)進(jìn)程就是ANR進(jìn)程欧募，而消耗CPU的這個(gè)事情往往就是導(dǎo)致ANR的根源压状。

2.3 內(nèi)存原因

內(nèi)存原因有可能會(huì)導(dǎo)致ANR, 例如如果由于內(nèi)存泄露, App可使用內(nèi)存所剩無幾.
// 以下trace信息來自網(wǎng)絡(luò), 用來做個(gè)示例

Cmdline: android.process.acore

DALVIK THREADS:
"main"prio=5 tid=3 VMWAIT
|group="main" sCount=1 dsCount=0 s=N obj=0x40026240self=0xbda8
| sysTid=1815 nice=0 sched=0/0 cgrp=unknownhandle=-1344001376
atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod)
atandroid.graphics.Bitmap.nativeCreate(Native Method)
atandroid.graphics.Bitmap.createBitmap(Bitmap.java:468)
atandroid.view.View.buildDrawingCache(View.java:6324)
atandroid.view.View.getDrawingCache(View.java:6178)

...

MEMINFO in pid 1360 [android.process.acore] **
native dalvik other total
size: 17036 23111 N/A 40147
allocated: 16484 20675 N/A 37159
free: 296 2436 N/A 2732

可以看到free的內(nèi)存已所剩無幾.

3 ANR的處理

三種不同的情況, 一般的處理情況如下
1.主線程阻塞

開辟單獨(dú)的子線程來處理耗時(shí)阻塞事務(wù).

2.CPU滿負(fù)荷, I/O阻塞

I/O阻塞一般來說就是文件讀寫或數(shù)據(jù)庫操作執(zhí)行在主線程了, 也可以通過開辟子線程的方式異步執(zhí)行.

3.內(nèi)存不夠用

增大VM內(nèi)存, 使用largeHeap屬性, 排查內(nèi)存泄露等.

感謝
1.ANR分析思路簡析-https://blog.csdn.net/sinat_34157462/article/details/78651870
2.Android應(yīng)用ANR分析-http://www.reibang.com/p/30c1a5ad63a3