ANR問題解決思路
Android應(yīng)用ANR分析
Android ANR 分析
FastJNI導(dǎo)致的Android系統(tǒng)死機(jī)問題分析
Android ANR問題 -- Input超時(shí)實(shí)戰(zhàn)問題解析上
判斷某線程或服務(wù)是否在處于空閑狀態(tài)：ANR分析
- 術(shù)語
nativePollOnce表示該線程的looper messagequeue中沒有消息唉侄，線程處于空閑狀態(tài)
epoll_wait表示該線程的looper處于等待狀態(tài)和nativePollOnce對應(yīng)
獲取ANR文件
- 在低系統(tǒng)版本籍滴，用
db pull data/anr/traces.txt就能獲取anr文件衍慎。 - 在高系統(tǒng)版本需要使用
adb bugreport pathName
獲取anr文件，比如adb bugreport /Users/hongjunmin/Desktop/ANR
將文件解壓后网严，可以在目錄bugreport-CPH1803-OPMXX/FS/data/anr下看到ANR文件
有時(shí)候會(huì)發(fā)現(xiàn)這個(gè)文件夾下沒有最新的ANR信息，這時(shí)候去bugreport-bullhead-OPM/bugreport-bullhead-OPM.txt文件里搜 "VM TRACES AT LAST ANR" 往下翻就是這次ANR的trace信息了
也可以通過開發(fā)者選項(xiàng)獲取并閱讀錯(cuò)誤報(bào)告
案例解析
案例1
ANR提示：
03-13 21:11:44.813 E/ANRManager( 820): ANR in com.my.fm
03-13 21:11:44.813 E/ANRManager( 820): Reason: Executing service com.my.fm/.common.downloadmgr.DownloadService
第一反應(yīng)是查看DownloadService的生命周期函數(shù)onCreate和onStartCommand里面有沒有耗時(shí)操作嗤无，檢查完畢震束，并沒有，懵逼当犯。
然后我在ANR日志中觀察到如下數(shù)據(jù)：
03-13 21:11:37.806 I/ANRManager( 820): getProcessState
03-13 21:11:37.808 I/ActivityManager( 820): Android time :[2017-03-13 21:11:37.805] [8809.438]
03-13 21:11:37.808 I/ActivityManager( 820): CPU usage from 7105ms to 27ms ago:
03-13 21:11:37.808 I/ActivityManager( 820): 98% 12850/com.my.fm: 98% user + 0.1% kernel / faults: 15 minor
03-13 21:11:37.808 I/ActivityManager( 820): 7% 3510/cn.testin.itestin:nserver: 5.9% user + 1.1% kernel / faults: 3367 minor
03-13 21:11:37.808 I/ActivityManager( 820): 5.7% 820/system_server: 3.2% user + 2.5% kernel / faults: 61 minor
03-13 21:11:37.808 I/ActivityManager( 820): 3.3% 246/surfaceflinger: 0.5% user + 2.8% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 2.1% 21712/com.android.launcher3: 0.9% user + 1.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 1.6% 297/adbd: 0.7% user + 0.9% kernel / faults: 120 minor
03-13 21:11:37.808 I/ActivityManager( 820): 1.2% 12711/com.lbe.security.meizu:service: 1.1% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.9% 3539/cn.testin.itestin:reader: 0.4% user + 0.5% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.7% 1342/com.meizu.cloud: 0.4% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.7% 12335/logcat: 0.1% user + 0.5% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.5% 6527/com.android.systemui: 0.2% user + 0.2% kernel / faults: 13 minor
03-13 21:11:37.808 I/ActivityManager( 820): 0.5% 19427/kworker/0:0: 0% user + 0.5% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.4% 6874/kworker/u16:3: 0% user + 0.4% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.2% 121/fence_worker: 0% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.2% 128/bat_thread_kthr: 0% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.2% 129/mtk charger_hv_: 0% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.2% 813/gsm0710muxd: 0% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.2% 12134/kworker/u16:0: 0% user + 0.2% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 8/rcu_preempt: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 57/cfinteractive: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 61/hps_main: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 225/healthd: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 241/netd: 0% user + 0.1% kernel / faults: 12 minor
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 11546/uiautomator: 0.1% user + 0% kernel / faults: 3 minor
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 30849/tx_thread: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% 30850/hif_thread: 0% user + 0.1% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0% 30851/rx_thread: 0% user + 0% kernel
03-13 21:11:37.808 I/ActivityManager( 820): +0% 12945/app_process: 0% user + 0% kernel
03-13 21:11:37.808 I/ActivityManager( 820): +0% 12961/top: 0% user + 0% kernel
03-13 21:11:37.808 I/ActivityManager( 820): 0.1% TOTAL: 0.1% user + 0% kernel + 0% softirq
03-13 21:11:37.808 I/ActivityManager( 820):
發(fā)現(xiàn)我們的應(yīng)用myapp占用CPU達(dá)到了98%
這時(shí)候就有另一個(gè)思路垢村，即使DownloadService本身沒有耗時(shí)操作，但是如果有另一個(gè)任務(wù)或者線程頻繁占用CPU,這么最終會(huì)拖累DownloadService的執(zhí)行嚎卫，同樣會(huì)引發(fā)DownloadService的ANR嘉栓。
接著觀察到下面的數(shù)據(jù)
"Thread-2250" prio=5 tid=13 SUSPENDED
| group="main" sCount=1 dsCount=0 obj=0x422a65c8 self=0x788a60a8
| sysTid=12902 nice=0 sched=0/0 cgrp=default handle=2022342448
| state=S schedstat=( 19713394162 221285073 1557 ) utm=1969 stm=2 core=2
at java.util.ArrayList.isEmpty(ArrayList.java:~323)
at java.util.Collections$SynchronizedCollection.isEmpty(Collections.java:410)
at com.my.fm.common.util.f.a(Tool.java:273)
at com.my.fm.common.downloadmgr.d$d.b(DownloadManager.java:1453)
at com.my.common.downloadmgr.d.run(DownloadManager.java:274)
好，有點(diǎn)可疑拓诸，我就去定位(DownloadManager.java:1453)這行代碼侵佃，發(fā)現(xiàn)這行代碼是在一個(gè)while死循環(huán)里運(yùn)行
@Override
public void run() {
super.run();
while (isRunning) { //isRunning在某些時(shí)候一直為true.
//DownloadManager code
}
}
}
雖然while循環(huán)在非主線程運(yùn)行，但是會(huì)一直請求CPU占用奠支，所以這處代碼就像地雷馋辈，如何改正呢？很簡單倍谜，使用Thread.sleep即可：
@Override
public void run() {
super.run();
while (isRunning) {
//my working code
//防止一直while占用大量CPU時(shí)間迈螟，造成ANR
try {
Thread.sleep(800);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
結(jié)論：不僅僅是不要在主線程做耗時(shí)操作，并發(fā)線程過多尔崔，或者非主線程長時(shí)間占用CPU, 同樣會(huì)造成UI卡頓井联。
