如何分析ANR問題？

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

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

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

造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時(shí)操作, 例如文件讀寫, 數(shù)據(jù)庫(kù)讀寫, 網(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線程對(duì)象 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)先級(jí) 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)識(shí)
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)存所剩無(wú)幾.
// 以下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)存已所剩無(wú)幾.

3 ANR的處理

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

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

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

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

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

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

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

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • ANR問題，相信是每位開發(fā)日常都會(huì)遇到的問題，對(duì)于這類問題的分析，按照官方的推薦，或網(wǎng)絡(luò)博客的總結(jié)思路能解決一定的...
    tiger桂閱讀 18,285評(píng)論 5贊 28
  • 進(jìn)程和線程 進(jìn)程 所有運(yùn)行中的任務(wù)通常對(duì)應(yīng)一個(gè)進(jìn)程,當(dāng)一個(gè)程序進(jìn)入內(nèi)存運(yùn)行時(shí),即變成一個(gè)進(jìn)程.進(jìn)程是處于運(yùn)行過程中...
    勝浩_ae28閱讀 5,260評(píng)論 0贊 23
  • 本文是我自己在秋招復(fù)習(xí)時(shí)的讀書筆記，整理的知識(shí)點(diǎn)，也是為了防止忘記，尊重勞動(dòng)成果，轉(zhuǎn)載注明出處哦！如果你也喜歡，那...
    波波波先森閱讀 11,646評(píng)論 4贊 56
  • 就算栽下一棵菩提，誠(chéng)心膜拜又如何，裝裝樣子，掩掩性子，人總有七情六欲的?！臈?翌日一早，本是疲倦的我卻早早起了...
    與無(wú)閱讀 707評(píng)論 2贊 1
  • 短短五天。我所在的原本安安靜靜的城市突然進(jìn)入了緊急急迫的狀態(tài)。 6月29號(hào)，突然接到通知，30號(hào)和1號(hào)要去滁州小崗...
    海北sunshine閱讀 318評(píng)論 0贊 0

友情鏈接更多精彩內(nèi)容