Android ANR無(wú)響應(yīng)分析解決方案
1.什么是 ANR
ANR:Application Not Responding ，即應(yīng)用無(wú)響應(yīng)
2.ANR 的類(lèi)型以及對(duì)比每種類(lèi)型的規(guī)避解決方法
ANR 一般有三種類(lèi)型：
1）KeyDispatchTimeout(5 seconds) 按鍵或觸摸事件在特定時(shí)間內(nèi)無(wú)響應(yīng)
2）BroadcastTimeout(10 seconds) BroadcastReceiver 在特定時(shí)間內(nèi)無(wú)法處理完成
3）ServiceTimeout(20 seconds or 200 seconds) 前臺(tái)服務(wù)：超時(shí)時(shí)間是 20s； 后臺(tái)服務(wù)，則超時(shí)時(shí)間是200s； Service 在特定的時(shí)間內(nèi)無(wú)法處理完成
2.1 KeyDispatchTimeout
Akey or touch event was not dispatched within the specified time （按鍵或觸摸事件在特定時(shí)間內(nèi)無(wú)響應(yīng)）
具體的超時(shí)時(shí)間的定義在 framework 下的
ActivityManagerService.java //How long we wait until we timeout on key dispatching. staticfinal int KEY_DISPATCHING_TIMEOUT = 5*1000
為什么會(huì)超時(shí)呢？ 超時(shí)時(shí)間的計(jì)數(shù)一般是從按鍵分發(fā)給 app 開(kāi)始。超時(shí)的原因一般有兩種 ： 1）當(dāng)前的事件沒(méi)有機(jī)會(huì)得到處理（即 UI 線(xiàn)程正在處理前一個(gè)事件，沒(méi)有及時(shí)的完成或者 looper 被某種原因阻塞住了） 2）當(dāng)前的事件正在處理，但沒(méi)有及時(shí)完成
如何避免 KeyDispatchTimeout？ 1）UI 線(xiàn)程盡量只做跟 UI 相關(guān)的工作 2）耗時(shí)的工作（比如數(shù)據(jù)庫(kù)操作， I/O ，連接網(wǎng)絡(luò)或者別的有可能阻礙 UI 線(xiàn)程的操作）把它放入單獨(dú)的線(xiàn)程處理 3）盡量用 Handler 來(lái)處理 UIthread 和別的 thread 之間的交互
至于Service和BroadcastReceiver ，和上面的分析同理，這里就不多說(shuō)了。
3.如何分析ANR日志？
先看個(gè) LOG：
04-01 13:12:11.572 I/InputDispatcher( 220): Application is not responding :Window{2b263310com.android.email/com.android.email.activity.SplitScreenActivitypaused=false}. 5009.8ms since event, 5009.5ms since waitstarted
04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity
04-01 13:12:14.123 I/Process( 220): Sending signal. PID: 21404 SIG: 3--- 發(fā)生ANR 的時(shí)間和生成 trace.txt 的時(shí)間
04-01 13:12:14.123 I/dalvikvm(21404):threadid=4: reacting to signal 3
……
04-0113:12:15.872 E/ActivityManager( 220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager( 220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 4361ms to 699ms ago ---- CPU 在 ANR 發(fā)生前的使用情況
04-0113:12:15.872 E/ActivityManager( 220): 5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%65/irq/170-cyttsp-: 0% user + 0.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%296/com.android.systemui: 0.5% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 3697ms to 4223ms later :-- ANR 后 CPU 的使用量
04-0113:12:15.872 E/ActivityManager( 220): 25%21404/com.android.email: 25% user + 0% kernel / faults: 191 minor
04-0113:12:15.872 E/ActivityManager( 220): 16% 21603/__eas(par.hakan: 16% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 7.2% 21406/GC: 7.2% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 1.8% 21409/Compiler: 1.8% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 5.5%220/system_server: 0% user + 5.5% kernel / faults: 1 minor
04-0113:12:15.872 E/ActivityManager( 220): 5.5% 263/InputDispatcher: 0% user + 5.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 32%TOTAL: 28% user + 3.7% kernel
從ANR日志中，我們看到了ANR in com.android.email關(guān)鍵字，然后接下來(lái)，我們看到Reason:keyDispatchingTimedOut，是在事件響應(yīng)里面超時(shí)了，但是具體在哪里，這里看不出來(lái)，但是這里可以看到一個(gè)信息，即：ANR的原因是CPU占用率高，任務(wù)得不到時(shí)間片去執(zhí)行，還是因?yàn)镮O密集，導(dǎo)致ANR，這個(gè)很重要，可以給我們之后分析具體的trace日志提供方向。
除了看 LOG ，解決 ANR 還得需要 trace.txt 文件，如何獲取呢？可以用如下命令獲取
$chmod 777 /data/anr $rm /data/anr/traces.txt $ps $kill -3 PID adb pull data/anr/traces.txt ./mytraces.txt
從 trace.txt 文件，看到最多的是如下的信息：
-----pid 21404 at 2011-04-01 13:12:14 ----- Cmdline: com.android.email DALVIK THREADS: (mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 hwll=0) "main" prio=5 tid=1 NATIVE | group="main" sCount=1 dsCount=0obj=0x2aad2248 self=0xcf70 | sysTid=21404 nice=0 sched=0/0cgrp=[fopen-error:2] handle=1876218976 atandroid.os.MessageQueue.nativePollOnce(Native Method) atandroid.os.MessageQueue.next(MessageQueue.java:119) atandroid.os.Looper.loop(Looper.java:110 ) at android.app.ActivityThread.main(ActivityThread.java:3688) at java.lang.reflect.Method.invokeNative(Native Method) atjava.lang.reflect.Method.invoke(Method.java:507) atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624) at dalvik.system.NativeStart.main(Native Method)
我們從這里看到，是主線(xiàn)程卡在了nativePollOnce這里，從之前小編分析過(guò)handler、MQ源碼可知，這個(gè)是消息隊(duì)列為空，在等待下一條消息入隊(duì)，進(jìn)行主線(xiàn)程喚醒，也就是說(shuō)主線(xiàn)程死在，一直等待，等待超時(shí)了。
小結(jié)： 如何調(diào)查并解決 ANR？
1）首先分析 log，看一下大概原因，如果能直接定位最好，但是一般這里直接定位不到的
2）從 trace.txt 文件查看調(diào)用 stack.
3）對(duì)照每個(gè)線(xiàn)程日志，看自己代碼
4）過(guò)程中，緊緊穿插一條主線(xiàn)，仔細(xì)查看 ANR 的成因（ iowait?block?memoryleak? ）
4.案例分析
4.1 IO wait舉例
Process:com.android.email Activity:com.android.email/.activity.MessageView Subject: keyDispatchingTimedOut CPU usage from 2550ms to -2814ms ago: 5%187 /system_server: 3.5% user + 1.4% kernel / faults: 86 minor 20major 4.4% 1134/com.android.email: 0.7% user + 3.7% kernel /faults: 38 minor 19 major 4% 372/com.android.eventstream: 0.7%user + 3.3% kernel / faults: 6 minor 1.1% 272/com.android.phone:0.9% user + 0.1% kernel / faults: 33 minor 0.9%252/com.android.systemui: 0.9% user + 0% kernel 0%409/com.android.eventstream.telephonyplugin: 0% user + 0% kernel /faults: 2 minor 0.1% 632/com.android.devicemonitor: 0.1% user + 0%kernel 100%TOTAL: 6.9% user + 8.2% kernel + 84%iowait -----pid 1134 at 2010-12-17 17:46:51 ----- Cmd line:com.android.email DALVIK THREADS: (mutexes: tll=0 tsl=0tscl=0 ghl=0 hwl=0 hwll=0) "main" prio=5 tid=1 WAIT |group="main" sCount=1 dsCount=0 obj=0x2aaca180self=0xcf20 | sysTid=1134 nice=0 sched=0/0 cgrp=[fopen-error:2]handle=1876218976 at java.lang.Object.wait(Native Method) -waiting on <0x2aaca218> (a java.lang.VMThread) atjava.lang.Thread.parkFor(Thread.java:1424) atjava.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48) atsun.misc.Unsafe.park(Unsafe.java:337) atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:157) atjava.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:808) atjava.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:841) atjava.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1171) atjava.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:200) atjava.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:261) atandroid.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:378) atandroid.database.sqlite.SQLiteCursor.<init>(SQLiteCursor.java:222) atandroid.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:53) atandroid.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1356) atandroid.database.sqlite.SQLiteDatabase.queryWithFactory(SQLiteDatabase.java:1235) atandroid.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1189) atandroid.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1271) atcom.android.email.provider.EmailProvider.query(EmailProvider.java:1098) atandroid.content.ContentProvider$Transport.query(ContentProvider.java:187) atandroid.content. ContentResolver.query (ContentResolver.java:268) atcom.android.email.provider.EmailContent$Message.restoreMessageWithId(EmailContent.java:648) atcom.android.email.Controller.setMessageRead(Controller.java:658) atcom.android.email.activity.MessageView.onMarkAsRead(MessageView.java:700) atcom.android.email.activity.MessageView.access$2500(MessageView.java:98) atcom.android.email.activity.MessageView$LoadBodyTask .onPostExecute(MessageView.java:1290) atcom.android.email.activity.MessageView$LoadBodyTask.onPostExecute(MessageView.java:1255) atandroid.os.AsyncTask.finish(AsyncTask.java:417) atandroid.os.AsyncTask.access$300(AsyncTask.java:127) at android.os.AsyncTask $InternalHandler.handleMessage (AsyncTask.java:429) atandroid.os.Handler.dispatchMessage(Handler.java:99) atandroid.os.Looper.loop(Looper.java:123) atandroid.app.ActivityThread.main(ActivityThread.java:3652) atjava.lang.reflect.Method.invokeNative(Native Method) atjava.lang.reflect.Method.invoke(Method.java:507) atcom.android.internal.os.ZygoteIn
我們從日志上，看到關(guān)鍵字84%iowait，而且對(duì)于cpu來(lái)說(shuō)，這段日志占用很少，說(shuō)明大概原因就是IO密集型導(dǎo)致，從下面日志中看到，有View、有ContentProvider、有Sqlite、有鎖，我們先大膽猜測(cè)一下，是否是在主線(xiàn)程里面，進(jìn)行了數(shù)據(jù)庫(kù)操作導(dǎo)致的？
具體看日志，我們代碼中應(yīng)該有在view內(nèi)部調(diào)用ContentResolver的地方，快搜一下，我們代碼中，是否有這樣的調(diào)用，果然一搜，的確有：
final Message message = Message . restoreMessageWithId (mProviderContext , messageId );
if ( message == null ) {
return ;
}
Account account = Account . restoreAccountWithId ( mProviderContext ,message . mAccountKey );
if ( account == null ) {
return ; //isMessagingController returns false for null, but let's make itclear.
}
if ( isMessagingController ( account )) {
new Thread () {
@Override
public void run () {
mLegacyController . processPendingActions ( message .mAccountKey );
}
}. start ();
}
發(fā)現(xiàn)問(wèn)題了沒(méi)有呢？這里在主線(xiàn)程中調(diào)用了Account . restoreAccountWithId ( mProviderContext ,message . mAccountKey );去查詢(xún)數(shù)據(jù)，如果正常系統(tǒng)資源不緊張的時(shí)候，這樣調(diào)用的確不會(huì)出現(xiàn)太大問(wèn)題，但是假設(shè)這個(gè)數(shù)據(jù)很大、或者系統(tǒng)當(dāng)前IO繁忙，這兒代碼不就執(zhí)行很慢，導(dǎo)致主線(xiàn)程事件處理超時(shí)了嗎？ 所以把代碼，簡(jiǎn)單改為如下，運(yùn)行沒(méi)有問(wèn)題了。
new Thread() {
final Message message = Message . restoreMessageWithId (mProviderContext , messageId );
if ( message == null ) {
return ;
}
Account account = Account . restoreAccountWithId ( mProviderContext ,message . mAccountKey );
if ( account == null ) {
return ; //isMessagingController returns false for null, but let's make itclear.
}
if(isMessagingController(account)) {
mLegacyController.processPendingActions(message.mAccountKey);
}
}.start();
4.2Memoryleak/Thread leak
11-1621:41:42.560 I/ActivityManager( 1190): ANR in process:android.process.acore (last in android.process.acore) 11-1621:41:42.560 I/ActivityManager( 1190): Annotation:keyDispatchingTimedOut 11-16 21:41:42.560 I/ActivityManager(1190): CPU usage: 11-16 21:41:42.560 I/ActivityManager( 1190):Load: 11.5 / 11.1 / 11.09 11-16 21:41:42.560 I/ActivityManager(1190): CPU usage from 9046ms to 4018ms ago: 11-16 21:41:42.560 I/ActivityManager( 1190): d.process.acore:98% = 97% user + 0% kernel / faults: 1134 minor 11-16 21:41:42.560 I/ActivityManager( 1190): system_server: 0% = 0% user + 0% kernel /faults: 1 minor 11-16 21:41:42.560 I/ActivityManager( 1190): adbd:0% = 0% user + 0% kernel 11-16 21:41:42.560 I/ActivityManager(1190): logcat: 0% = 0% user + 0% kernel 11-16 21:41:42.560 I/ActivityManager( 1190): TOTAL:100% = 98% user + 1% kernel 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) atandroid.view.ViewGroup.drawChild(ViewGroup.java:1541) atcom.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:1830) atandroid.view.ViewRoot.draw(ViewRoot.java:1349) atandroid.view.ViewRoot.performTraversals(ViewRoot.java:1114) atandroid.view.ViewRoot.handleMessage(ViewRoot.java:1633) atandroid.os.Handler.dispatchMessage(Handler.java:99) atandroid.os.Looper.loop(Looper.java:123) atandroid.app.ActivityThread.main(ActivityThread.java:4370) atjava.lang.reflect.Method.invokeNative(Native Method) atjava.lang.reflect.Method.invoke(Method.java:521) atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868) atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:626) atdalvik.system.NativeStart.main(Native Method) "Thread-408"prio=5 tid=329 WAIT |group="main" sCount=1 dsCount=0 s=N obj=0x46910d40self=0xcd0548 | sysTid=10602 nice=0 sched=0/0 cgrp=unknownhandle=15470792 at java.lang.Object.wait(Native Method) -waiting on <0x468cd420> (a java.lang.Object) atjava.lang.Object.wait(Object.java:288) atcom.android.dialer.CallLogContentHelper$UiUpdaterExecutor$1.run(CallLogContentHelper.java:289) atjava.lang.Thread.run(Thread.java:1096)
我們看到日志中，ANR發(fā)生在VMRuntime中，有關(guān)鍵字Bitmap、createBitmap 、nativeCreate、ViewRoot、ActivityThread#main，我們大膽猜測(cè)一下，是否是在主線(xiàn)程視圖繪制函數(shù)中，進(jìn)行了大圖片的加載、申請(qǐng)了bitmap沒(méi)有釋放導(dǎo)致，仔細(xì)看日志，發(fā)現(xiàn)at dalvik.system. VMRuntime.trackExternalAllocation (NativeMethod ) ，bitmap在申請(qǐng)內(nèi)存的時(shí)候，不夠了，這時(shí)block了。
解決很簡(jiǎn)單，這時(shí)根據(jù)后面的線(xiàn)程、進(jìn)程、堆棧詳細(xì)信息，去反向猜測(cè)&查找相關(guān)代碼，是否存在可能內(nèi)存泄露的地方。
以上就是Android ANR無(wú)響應(yīng)分析解決方案的詳細(xì)內(nèi)容，更多關(guān)于Android ANR無(wú)響應(yīng)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
Android應(yīng)用程序簽名步驟及相關(guān)知識(shí)介紹
本文主要介紹Android應(yīng)用程序簽名相關(guān)的理論知識(shí)，包括：什么是簽名、為什么要給應(yīng)用程序簽名、如何給應(yīng)用程序簽名等,感興趣的朋友可以參考下哈2013-04-04
Android實(shí)現(xiàn)文字動(dòng)態(tài)高亮讀取進(jìn)度效果
這篇文章主要為大家詳細(xì)介紹了Android實(shí)現(xiàn)文字動(dòng)態(tài)高亮讀取進(jìn)度效果，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-05-05
Kotlin自定義View系列教程之標(biāo)尺控件（選擇身高、體重等）的實(shí)現(xiàn)
這篇文章主要給大家介紹了關(guān)于Kotlin自定義View系列教程之標(biāo)尺控件（選擇身高、體重等）實(shí)現(xiàn)的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，需要的朋友可以參考借鑒，下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2018-07-07
這篇文章主要介紹了Android源碼中常用的接口傳參實(shí)例詳解的相關(guān)資料,需要的朋友可以參考下2017-04-04
Android自定義控件之繼承ViewGroup創(chuàng)建新容器
這篇文章主要介紹了Android自定義控件之繼承ViewGroup創(chuàng)建新容器,具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2016-12-12
Android App開(kāi)發(fā)中使用RecyclerView替代ListView的實(shí)踐
RecyclerView是Android L即5.0版本以來(lái)新加入的一個(gè)組件,主要用來(lái)實(shí)現(xiàn)item的瀑布式排列,因而被人們廣泛認(rèn)為用來(lái)替代ListView,這里我們就來(lái)看一下Android App開(kāi)發(fā)中使用RecyclerView替代ListView的實(shí)踐:2016-06-06
Android開(kāi)發(fā)之電話(huà)撥號(hào)器實(shí)例詳解
這篇文章主要介紹了Android開(kāi)發(fā)之電話(huà)撥號(hào)器,結(jié)合實(shí)例形式詳細(xì)分析了Android電話(huà)撥號(hào)器的實(shí)現(xiàn)步驟與具體代碼,并附帶了一個(gè)Android開(kāi)放電話(huà)撥號(hào)器的學(xué)習(xí)筆記,需要的朋友可以參考下2015-12-12
Qt6.5.3?Android環(huán)境配置的實(shí)現(xiàn)
本文主要介紹了Qt6.5.3?Android環(huán)境配置的實(shí)現(xiàn),文中通過(guò)圖文介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2024-01-01
這篇文章主要介紹了Action獲取請(qǐng)求參數(shù)的三種方式的,非常不錯(cuò)，具有參考借鑒價(jià)值,需要的朋友可以參考下2016-06-06
這篇文章主要為大家詳細(xì)介紹了Android仿通話(huà)來(lái)電界面效果，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-09-09