為什么會(huì)產(chǎn)生
一般是在“主”線程中進(jìn)行一些長(zhǎng)時(shí)間的操作時(shí)霎迫，會(huì)發(fā)生ANR锭部。這是事件循環(huán)線程，如果繁忙，則Android無(wú)法處理應(yīng)用程序中的任何其他GUI事件卒蘸，因此會(huì)引發(fā)ANR
出現(xiàn)以下任何情況時(shí)，系統(tǒng)都會(huì)針對(duì)您的應(yīng)用觸發(fā) ANR：
- 當(dāng)您的 Activity 位于前臺(tái)時(shí)趣避，您的應(yīng)用在 5 秒鐘內(nèi)未響應(yīng)輸入事件或BroadcastReceiver（如按鍵或屏幕輕觸事件）
- 雖然前臺(tái)沒(méi)有 Activity尸执，但您的 BroadcastReceiver 用了相當(dāng)長(zhǎng)的時(shí)間仍未執(zhí)行完畢。
出現(xiàn)的場(chǎng)景
打開(kāi)app,每次進(jìn)入購(gòu)物車模塊,當(dāng)網(wǎng)絡(luò)狀態(tài)不好的時(shí)候,再切換到其它模塊就會(huì)出現(xiàn)ANR
診斷 ANR
診斷 ANR 時(shí)需要考慮以下幾種常見(jiàn)模式：
- 應(yīng)用在主線程上非常緩慢地執(zhí)行涉及 I/O 的操作浸卦。
- 應(yīng)用在主線程上進(jìn)行長(zhǎng)時(shí)間的計(jì)算署鸡。
- 主線程在對(duì)另一個(gè)進(jìn)程進(jìn)行同步 binder 調(diào)用，而后者需要很長(zhǎng)時(shí)間才能返回。
- 主線程處于阻塞狀態(tài)靴庆，為發(fā)生在另一個(gè)線程上的長(zhǎng)操作等待同步的塊时捌。(本次ANR屬于這種情況)
- 主線程在進(jìn)程中或通過(guò) binder 調(diào)用與另一個(gè)線程之間發(fā)生死鎖。主線程不只是在等待長(zhǎng)操作執(zhí)行完畢炉抒，而且處于死鎖狀態(tài)奢讨。
分析步驟
- 看Logcat打印
ANR in 包名 (包名/.MainActivity)
PID: 15350
Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. waitqueue length = 8, head.seq = 3376085, Wait queue head age: 8115.9ms.)
Parent: 包名/.MainActivity
Load: 0.0 / 0.0 / 0.0
CPU usage from 24627ms to 0ms ago (2020-01-15 16:59:46.273 to 2020-01-15 17:00:10.900):
26% 1254/system_server: 18% user + 7.8% kernel / faults: 109111 minor 1 major
1.1% 15350/usap64: 0.9% user + 0.1% kernel / faults: 141417 minor
12% 2127/com.android.systemui: 9.4% user + 2.9% kernel / faults: 28273 minor 3 major
9.1% 704/surfaceflinger: 4.3% user + 4.7% kernel / faults: 966 minor
6.7% 788/aptouch_daemon: 5.9% user + 0.7% kernel / faults: 137 minor
5.6% 662/android.hardware.graphics.composer@2.2-service: 1.9% user + 3.6% kernel / faults: 101 minor
5.2% 678/vendor.huawei.hardware.hwdisplay.displayengine@1.2-service: 3.2% user + 2% kernel / faults: 76 minor
4.8% 13166/usap64: 3.6% user + 1.1% kernel / faults: 14193 minor
4% 7836/adbd: 0.9% user + 3% kernel / faults: 280 minor
3.3% 477/logd: 0.8% user + 2.5% kernel / faults: 95 minor
3.1% 842/dubaid: 1.8% user + 1.2% kernel / faults: 1369 minor
2.2% 6143/kworker/u16:9: 0% user + 2.2% kernel
2.2% 2433/com.android.phone: 1.3% user + 0.8% kernel / faults: 2189 minor
2% 661/android.hardware.graphics.allocator@2.0-service: 0% user + 2% kernel / faults: 169 minor
2% 6343/kworker/u16:26: 0% user + 2% kernel
2% 1866/pcie_rc_pm: 0% user + 2% kernel
0.3% 15547/kworker/u16:2: 0% user + 0.3% kernel / faults: 1 minor
1.8% 16445/kworker/u16:7: 0% user + 1.8% kernel
1.7% 17685/logcat: 0.4% user + 1.3% kernel / faults: 33 minor
1.6% 711/powerlogd: 1% user + 0.5% kernel / faults: 3 minor
1.5% 540/icc_shared: 0% user + 1.5% kernel
1.5% 2152/com.huawei.systemserver: 0.8% user + 0.6% kernel / faults: 805 minor
1.4% 282/irq/213-thp: 0% user + 1.4% kernel
1.4% 478/servicemanager: 0.5% user + 0.8% kernel / faults: 29 minor
1.3% 2165/com.huawei.iaware: 0.9% user + 0.4% kernel / faults: 1864 minor
1.3% 877/hwpged: 0.2% user + 1% kernel / faults: 6 minor
1.2% 98/sys_heap: 0% user + 1.2% kernel
1.2% 5807/usap64: 0.6% user + 0.5% kernel / faults: 1607 minor
1.1% 840/displayengineserver: 0.5% user + 0.6% kernel / faults: 82 minor
1.1% 917/hiview: 0.2% user + 0.9% kernel / faults: 1029 minor 5 major
1.1% 16453/kworker/u16:16: 0% user + 1.1% kernel
1% 95/spi3: 0% user + 1% kernel
1% 858/CameraDaemon: 0.3% user + 0.6% kernel / faults: 5435 minor
0.9% 689/vendor.huawei.hardware.light@2.0-service: 0% user + 0.8% kernel / faults: 25 minor
0.9% 2141/com.huawei.hiview: 0.6% user + 0.3% kernel / faults: 927 minor
0.8% 179/kswapd0: 0% user + 0.8% kernel
0.7% 7880/chargelogcat-c: 0% user + 0.7% kernel / faults: 41 minor
0.7% 28696/usap64: 0.3% user + 0.3% kernel / faults: 655 minor
0.6% 24391/usap32: 0.4% user + 0.2% kernel / faults: 260 minor
0.6% 9/rcu_preempt: 0% user + 0.6% kernel
0.6% 17627/usap64: 0.4% user + 0.1% kernel / faults: 1169 minor
0.5% 834/vendor.huawei.hardware.biometrics.hwfacerecognize@1.1-service: 0.2% user + 0.3% kernel / faults: 2832 minor
0.5% 946/vendor.huawei.hardware.biometrics.fingerprint@2.2-service: 0% user + 0.5% kernel / faults: 109 minor
0.4% 703/lmkd: 0% user + 0.4% kernel / faults: 23 minor
0.4% 3284/sugov:0: 0% user + 0.4% kernel
0.4% 24402/usap32: 0.2% user + 0.2% kernel / faults: 718 minor 7 major
0.4% 638/netd: 0% user + 0.3% kernel / faults: 1025 minor
0.4% 692/vendor.huawei.hardware.perfgenius@2.0-service: 0% user + 0.3% kernel / faults: 46 minor
0.4% 4158/com.huawei.recsys: 0.3% user + 0% kernel / faults: 304 minor
0.4% 6206/kworker/u17:2: 0% user + 0.4% kernel
0.4% 15044/kworker/u17:3: 0% user + 0.4% kernel
0.3% 1/init: 0.2% user + 0.1% kernel / faults: 75 minor
0.3% 6217/usap32: 0.1% user + 0.2% kerne
分析: 這里可以看出是哪個(gè)Activity導(dǎo)致ANR,而且可以排除不是cpu負(fù)載過(guò)高引起的
- 查看拉取跟蹤信息文件(traces.txt)
Android 會(huì)在遇到 ANR 時(shí)存儲(chǔ)跟蹤信息。在較低的操作系統(tǒng)版本中焰薄，設(shè)備上只有一個(gè) /data/anr/traces.txt 文件拿诸。在較新的操作系統(tǒng)版本中，有多個(gè) /data/anr/anr_* 文件塞茅。
也可以使用設(shè)備上的“生成錯(cuò)誤報(bào)告”開(kāi)發(fā)者選項(xiàng)或開(kāi)發(fā)機(jī)器上的 adb bugreport 命令
下面是我在華為手機(jī)上打印的traces.txt
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 flags=1 obj=0x71df12f8 self=0x7e7de10800
| sysTid=12750 nice=-10 cgrp=default sched=1073741825/1 handle=0x7f04c22ed0
| state=S schedstat=( 912713528 81383848 2003 ) utm=67 stm=23 core=4 HZ=100
| stack=0x7fc9a10000-0x7fc9a12000 stackSize=8192KB
| held mutexes=
at 包名support.network.f.a(HttpManager.java:-1)
- waiting to lock <0x09bbae37> (a 包名support.network.f) held by thread 4
at 包名support.network.c.b(MyHttpClient.java:3)
at 包名c.a.a.a(AsyncPrice.java:56)
at 包名model.account.fragment.AccountNewFragment.J(AccountNewFragment.java:5)
at 包名model.account.fragment.AccountNewFragment.t(AccountNewFragment.java:69)
at 包名model.base.fragment.a.onViewCreated(BaseFragment.java:5)
at androidx.fragment.app.g.a(FragmentManager.java:236)
at androidx.fragment.app.g.i(FragmentManager.java:6)
at androidx.fragment.app.g.a(FragmentManager.java:330)
at androidx.fragment.app.a.f(BackStackRecord.java:24)
at androidx.fragment.app.g.a(FragmentManager.java:445)
at androidx.fragment.app.g.b(FragmentManager.java:66)
at androidx.fragment.app.g.c(FragmentManager.java:56)
at androidx.fragment.app.g.p(FragmentManager.java:8)
at androidx.fragment.app.g.b(FragmentManager.java:5)
at 包名MainActivity$v.onNavigationItemSelected(MainActivity.java:75)
at com.google.android.material.bottomnavigation.BottomNavigationView$1.onMenuItemSelected(BottomNavigationView.java:3)
at androidx.appcompat.view.menu.h.dispatchMenuItemSelected(MenuBuilder.java:1)
at androidx.appcompat.view.menu.k.g(MenuItemImpl.java:2)
at androidx.appcompat.view.menu.h.performItemAction(MenuBuilder.java:4)
at com.google.android.material.bottomnavigation.BottomNavigationMenuView$1.onClick(BottomNavigationMenuView.java:3)
at android.view.View.performClick(View.java:7199)
at android.view.View.performClickInternal(View.java:7173)
at android.view.View.access$3500(View.java:824)
at android.view.View$PerformClick.run(View.java:27623)
at android.os.Handler.handleCallback(Handler.java:894)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:213)
at android.app.ActivityThread.main(ActivityThread.java:8201)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1101)
這里看出是在MyHttpClient中執(zhí)行了一個(gè)請(qǐng)求導(dǎo)致的,剛開(kāi)始懷疑是在主線程中執(zhí)行了這個(gè)耗時(shí)的請(qǐng)求才導(dǎo)致的,后面查看代碼并不是這樣
是在一個(gè)線程池里面執(zhí)行的這個(gè)請(qǐng)求,但是代碼這里為這個(gè)線程加了鎖,當(dāng)這個(gè)請(qǐng)求一直沒(méi)有返回結(jié)果的時(shí)候,從而導(dǎo)致主線程一直等待,沒(méi)有響應(yīng)
