如何分析解決Android ANR

參考文檔：  
http://blog.csdn.net/tjy1985/article/details/6777346  
http://blog.csdn.net/tjy1985/article/details/6777355  
http://blog.csdn.net/tjy1985/article/details/6777983  
http://www.eoeandroid.com/forum.php?mod=viewthread&tid=165974

====================================================

一：什么是ANR
ANR:Application Not Responding，即應(yīng)用無響應(yīng)

二：ANR的類型
ANR一般有三種類型：
1：KeyDispatchTimeout(5 seconds) --主要類型
按鍵或觸摸事件在特定時(shí)間內(nèi)無響應(yīng)
2：BroadcastTimeout(10 seconds)
BroadcastReceiver在特定時(shí)間內(nèi)無法處理完成
3：ServiceTimeout(20 seconds) --小概率類型
Service在特定的時(shí)間內(nèi)無法處理完成

三：KeyDispatchTimeout
Akey or touch event was not dispatched within the specified time（按鍵或觸摸事件在特定時(shí)間內(nèi)無響應(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開始。超時(shí)的原因一般有兩種：
(1)當(dāng)前的事件沒有機(jī)會(huì)得到處理（即UI線程正在處理前一個(gè)事件，沒有及時(shí)的完成或者looper被某種原因阻塞住了）
(2)當(dāng)前的事件正在處理，但沒有及時(shí)完成

五：如何避免KeyDispatchTimeout
1：UI線程盡量只做跟UI相關(guān)的工作
2：耗時(shí)的工作（比如數(shù)據(jù)庫(kù)操作，I/O，連接網(wǎng)絡(luò)或者別的有可能阻礙UI線程的操作）把它放入單獨(dú)的線程處理
3：盡量用Handler來處理UIthread和別的thread之間的交互

六：UI線程
說了那么多的UI線程，那么哪些屬于UI線程呢？
UI線程主要包括如下：

  • Activity:onCreate(), onResume(), onDestroy(), onKeyDown(), onClick(),etc

  • AsyncTask: onPreExecute(), onProgressUpdate(), onPostExecute(), onCancel,etc

  • Mainthread handler: handleMessage(), post*(runnable r), etc

  • other

七:如何去分析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

從LOG可以看出ANR的類型，CPU的使用情況，如果CPU使用量接近100%，說明當(dāng)前設(shè)備很忙，有可能是CPU饑餓導(dǎo)致了ANR
如果CPU使用量很少，說明主線程被BLOCK了
如果IOwait很高，說明ANR有可能是主線程在進(jìn)行I/O操作造成的
除了看LOG，解決ANR還得需要trace.txt文件，
如何獲取呢？可以用如下命令獲取

$chmod 777 /data/anr

$rm /data/anr/traces.txt

$ps

$kill -3 PID

adbpull data/anr/traces.txt ./mytraces.txt

從trace.txt文件，看到最多的是如下的信息：
-----pid 21404 at 2011-04-01 13:12:14 ----- Cmdline: com.android.emailDALVIK THREADS:(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)"main" prio=5 tid=1NATIVE | 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)

說明主線程在等待下條消息進(jìn)入消息隊(duì)列

八：Thread狀態(tài)

ThreadState (defined at “dalvik/vm/thread.h “)  
THREAD_UNDEFINED = -1, /* makes enum compatible with int32_t */  
THREAD_ZOMBIE = 0, /* TERMINATED */  
THREAD_RUNNING = 1, /* RUNNABLE or running now */  
THREAD_TIMED_WAIT = 2, /* TIMED_WAITING in Object.wait() */  
THREAD_MONITOR = 3, /* BLOCKED on a monitor */  
THREAD_WAIT = 4, /* WAITING in Object.wait() */  
THREAD_INITIALIZING= 5, /* allocated, not yet running */  
THREAD_STARTING = 6, /* started, not yet on thread list */  
THREAD_NATIVE = 7, /* off in a JNI native method */  
THREAD_VMWAIT = 8, /* waiting on a VM resource */  
THREAD_SUSPENDED = 9, /* suspended, usually by GC or debugger */

九：如何調(diào)查并解決ANR
1：首先分析log
2: 從trace.txt文件查看調(diào)用stack.
3: 看代碼
4：仔細(xì)查看ANR的成因（iowait?block?memoryleak?）

十：案例
案例1：關(guān)鍵詞:ContentResolver in AsyncTask onPostExecute, high iowait
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.ReentrantLockFairSync.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.ContentProviderTransport.query(ContentProvider.java:187)
atandroid.content.ContentResolver.query(ContentResolver.java:268)
atcom.android.email.provider.EmailContentMessage.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.access2500(MessageView.java:98)
atcom.android.email.activity.MessageViewLoadBodyTask.onPostExecute**(MessageView.java:1290) atcom.android.email.activity.MessageViewLoadBodyTask.onPostExecute(MessageView.java:1255)
atandroid.os.AsyncTask.finish(AsyncTask.java:417)
atandroid.os.AsyncTask.access300(AsyncTask.java:127) **atandroid.os.AsyncTaskInternalHandler.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

原因：****IOWait****很高，說明當(dāng)前系統(tǒng)在忙于****I/O****，因此數(shù)據(jù)庫(kù)操作被阻塞
原來：

  finalMessagemessage=Message.restoreMessageWithId(mProviderContext,messageId);

        if(message==null){

           return;

        }

        Accountaccount=Account.restoreAccountWithId(mProviderContext,message.mAccountKey);

        if(account==null){

           return;//isMessagingController returns false for null, but let's make itclear.

        }

        if(isMessagingController(account)){

           newThread(){

               @Override

               publicvoidrun(){

                  mLegacyController.processPendingActions(message.mAccountKey);

               }

           }.start();

        }

解決后：

newThread() {
  finalMessagemessage=Message.restoreMessageWithId(mProviderContext,messageId);

        if(message==null){

           return;

        }

        Accountaccount=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();

AsyncTask:http://developer.android.com/reference/android/os/AsyncTask.html

案例2：關(guān)鍵詞:在UI線程進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)的讀寫

ANRin process: com.android.mediascape:PhotoViewer (last incom.android.mediascape:PhotoViewer)
Annotation:keyDispatchingTimedOut
CPU usage:
Load: 6.74 / 6.89 / 6.12
CPUusage from 8254ms to 3224ms ago:
ovider.webmedia: 4% = 4% user +0% kernel / faults: 68 minor
system_server: 2% = 1% user + 0%kernel / faults: 18 minor
re-initialized>: 0% = 0% user + 0%kernel / faults: 50 minor
events/0: 0% = 0% user + 0%kernel
TOTAL:7% = 6% user + 1% kernel

DALVIKTHREADS:
""main"" prio=5 tid=3 NATIVE
|group=""main"" sCount=1 dsCount=0 s=Yobj=0x4001b240 self=0xbda8
| sysTid=2579 nice=0 sched=0/0cgrp=unknown handle=-1343993184
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStreamImpl(NativeMethod)
atorg.apache.harmony.luni.platform.OSNetworkSystem.receiveStream(OSNetworkSystem.java:478)
atorg.apache.harmony.luni.NET.PlainSocketImpl.read(PlainSocketImpl.java:565)
atorg.apache.harmony.luni.net.SocketInputStream.read(SocketInputStream.java:87)
atorg.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnectionLimitedInputStream.read(HttpURLConnection.java:303) atjava.io.InputStream.read(InputStream.java:133) atjava.io.BufferedInputStream.fillbuf(BufferedInputStream.java:157) atjava.io.BufferedInputStream.read(BufferedInputStream.java:346) atandroid.graphics.BitmapFactory.nativeDecodeStream(Native Method) atandroid.graphics.**BitmapFactory.decodeStream**(BitmapFactory.java:459) atcom.android.mediascape.activity.PhotoViewerActivity.**getPreviewImage**(PhotoViewerActivity.java:4465) atcom.android.mediascape.activity.PhotoViewerActivity.**dispPreview**(PhotoViewerActivity.java:4406) atcom.android.mediascape.activity.PhotoViewerActivity.access6500(PhotoViewerActivity.java:125)atcom.android.mediascape.activity.PhotoViewerActivity33****1.run(PhotoViewerActivity.java:4558)
atandroid.os.Handler.handleCallback(Handler.java:587)
atandroid.os.Handler.dispatchMessage(Handler.java:92)
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)
關(guān)于網(wǎng)絡(luò)連接，再設(shè)計(jì)的時(shí)候可以設(shè)置個(gè)timeout的時(shí)間或者放入獨(dú)立的線程來處理。
關(guān)于Handler的問題，可以參考：http://developer.android.com/reference/android/os/Handler.html
案例3：
關(guān)鍵詞：Memoryleak/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.560I/ActivityManager(1190): d.process.acore:98%= 97% user + 0% kernel / faults: 1134 minor
11-16 21:41:42.560I/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.560I/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.PhoneWindowDecorView.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.ZygoteInitMethodAndArgsCaller.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.CallLogContentHelperUiUpdaterExecutor1.run(CallLogContentHelper.java:289)
atjava.lang.Thread.run(Thread.java:1096)
分析：
atdalvik.system.VMRuntime.trackExternalAllocation**(NativeMethod)內(nèi)存不足導(dǎo)致block在創(chuàng)建bitmap上
**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
解決：如果機(jī)器的內(nèi)存族，可以修改虛擬機(jī)的內(nèi)存為36M或更大，不過最好是復(fù)查代碼，查看哪些內(nèi)存沒有釋放

Log的產(chǎn)生大家都知道 ， 大家也都知道通過DDMS來看log ， 但什么時(shí)候會(huì)產(chǎn)生log文件呢 ？一般在如下幾種情況會(huì)產(chǎn)生log文件 。
1，程序異常退出 ， uncaused exception
2，程序強(qiáng)制關(guān)閉 ，F(xiàn)orce Closed (簡(jiǎn)稱FC)
3，程序無響應(yīng) ， Application No Response （簡(jiǎn)稱ANR) ， 順便，一般主線程超過5秒么有處理就會(huì)ANR
4，手動(dòng)生成 。

拿到一個(gè)日志文件，要分成多段來看 。 log文件很長(zhǎng)，其中包含十幾個(gè)小單元信息，但不要被嚇到 ，事實(shí)上他主要由三大塊兒組成 。

1，系統(tǒng)基本信息 ，包括 內(nèi)存，CPU ，進(jìn)程隊(duì)列 ，虛擬內(nèi)存 ， 垃圾回收等信息 。
------ MEMORY INFO (/proc/meminfo) ------
------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------
------ PROCRANK (procrank) ------
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
------ VMALLOC INFO (/proc/vmallocinfo) ------

格式如下：
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 347076 kB
MemFree: 56408 kB
Buffers: 7192 kB
Cached: 104064 kB
SwapCached: 0 kB
Active: 192592 kB
Inactive: 40548 kB
Active(anon): 129040 kB
Inactive(anon): 1104 kB
Active(file): 63552 kB
Inactive(file): 39444 kB
Unevictable: 7112 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 44 kB
Writeback: 0 kB
AnonPages: 129028 kB
Mapped: 73728 kB
Shmem: 1148 kB
Slab: 13072 kB
SReclaimable: 4564 kB
SUnreclaim: 8508 kB
KernelStack: 3472 kB
PageTables: 12172 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 173536 kB
Committed_AS: 7394524 kB
VmallocTotal: 319488 kB
VmallocUsed: 90752 kB
VmallocChunk: 181252 kB

2，時(shí)間信息 ， 也是我們主要分析的信息 。
------ VMALLOC INFO (/proc/vmallocinfo) ------
------ EVENT INFO (/proc/vmallocinfo) ------

格式如下：
------ SYSTEM LOG (logcat -b system -v time -d *:v) ------
01-15 16:41:43.671 W/PackageManager(2466): Unknown permission com.wsomacp.permission.PROVIDER in package com.android.mms
01-15 16:41:43.671 I/ActivityManager(2466): Force stopping package com.android.mms uid=10092
01-15 16:41:43.675 I/UsageStats(2466): Something wrong here, didn't expect com.sec.android.app.twlauncher to be paused
01-15 16:41:44.108 I/ActivityManager(2466): Start proc com.sec.android.widgetapp.infoalarm for service com.sec.android.widgetapp.infoalarm/.engine.DataService: pid=20634 uid=10005 gids={3003, 1015, 3002}
01-15 16:41:44.175 W/ActivityManager(2466): Activity pause timeout for HistoryRecord{48589868 com.sec.android.app.twlauncher/.Launcher}
01-15 16:41:50.864 I/KeyInputQueue(2466): Input event
01-15 16:41:50.866 D/KeyInputQueue(2466): screenCaptureKeyFlag setting 0
01-15 16:41:50.882 I/PowerManagerService(2466): Ulight 0->7|0
01-15 16:41:50.882 I/PowerManagerService(2466): Setting target 2: cur=0.0 target=70 delta=4.6666665 nominalCurrentValue=0
01-15 16:41:50.882 I/PowerManagerService(2466): Scheduling light animator!
01-15 16:41:51.706 D/PowerManagerService(2466): enableLightSensor true
01-15 16:41:51.929 I/KeyInputQueue(2466): Input event
01-15 16:41:51.933 W/WindowManager(2466): No focus window, dropping: KeyEvent{action=0 code=26 repeat=0 meta=0 scancode=26 mFlags=9}

3，虛擬機(jī)信息 ， 包括進(jìn)程的，線程的跟蹤信息，這是用來跟蹤進(jìn)程和線程具體點(diǎn)的好地方 。
------ VM TRACES JUST NOW (/data/anr/traces.txt.bugreport: 2011-01-15 16:49:02) ------
------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-01-15 16:49:02) ------

格式如下 ：
----- pid 21161 at 2011-01-15 16:49:01 -----
Cmd line: com.android.mms

DALVIK THREADS:
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x4001d8d0 self=0xccc8
| sysTid=21161 nice=0 sched=0/0 cgrp=default handle=-1345017808
| schedstat=( 4151552996 5342265329 10995 )
at android.media.MediaPlayer._reset(Native Method)
at android.media.MediaPlayer.reset(MediaPlayer.java:1218)
at android.widget.VideoView.release(VideoView.java:499)
at android.widget.VideoView.access2100(VideoView.java:50) at android.widget.VideoView6.surfaceDestroyed(VideoView.java:489)
at android.view.SurfaceView.reportSurfaceDestroyed(SurfaceView.java:572)
at android.view.SurfaceView.updateWindow(SurfaceView.java:476)
at android.view.SurfaceView.onWindowVisibilityChanged(SurfaceView.java:206)
at android.view.View.dispatchDetachedFromWindow(View.java:6082)
at android.view.ViewGroup.dispatchDetachedFromWindow(ViewGroup.java:1156)
at android.view.ViewGroup.removeAllViewsInLayout(ViewGroup.java:2296)
at android.view.ViewGroup.removeAllViews(ViewGroup.java:2254)
at com.android.mms.ui.SlideView.reset(SlideView.java:687)
at com.android.mms.ui.SlideshowPresenter.presentSlide(SlideshowPresenter.java:189)
at com.android.mms.ui.SlideshowPresenter3.run(SlideshowPresenter.java:531) at android.os.Handler.handleCallback(Handler.java:587) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:123) at android.app.ActivityThread.main(ActivityThread.java:4627) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:521) at com.android.internal.os.ZygoteInitMethodAndArgsCaller.run(ZygoteInit.java:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)

閑話少說， 我總結(jié)了觀察log文件的基本步驟 。 1，如果是ANR問題 ， 則搜索“ANR”關(guān)鍵詞 。 快速定位到關(guān)鍵事件信息 。
2，如果是ForceClosed 和其它異常退出信息，則搜索"Fatal" 關(guān)鍵詞， 快速定位到關(guān)鍵事件信息 。
3，定位到關(guān)鍵事件信息后 ， 如果信息不夠明確的，再去搜索應(yīng)用程序包的虛擬機(jī)信息 ，查看具體的進(jìn)程和線程跟蹤的日志，來定位到代碼 。

用這種方法，出現(xiàn)問題，根本不需要斷點(diǎn)調(diào)試 ， 直接定位到問題，屢試不爽 。
下面，我們就開始來分析這個(gè)例子的log 。

打開log文件 ， 由于是ANR錯(cuò)誤，因此搜索"ANR " ， 為何要加空格呢，你加上和去掉比較一下就知道了 。 可以屏蔽掉不少保存到anr.log文件的無效信息 。

定位到關(guān)鍵的事件信息如下：
01-15 16:49:02.433 E/ActivityManager(2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)
01-15 16:49:02.433 E/ActivityManager(2466): Reason: keyDispatchingTimedOut
01-15 16:49:02.433 E/ActivityManager(2466): Load: 0.6 / 0.61 / 0.42
01-15 16:49:02.433 E/ActivityManager(2466): CPU usage from 1337225ms to 57ms ago:
01-15 16:49:02.433 E/ActivityManager(2466): sensorserver_ya: 8% = 0% user + 8% kernel / faults: 40 minor
......

01-15 16:49:02.433 E/ActivityManager(2466): -com.android.mms: 0% = 0% user + 0% kernel
01-15 16:49:02.433 E/ActivityManager(2466): -flush-179:8: 0% = 0% user + 0% kernel
01-15 16:49:02.433 E/ActivityManager(2466): TOTAL: 25% = 10% user + 14% kernel + 0% iowait + 0% irq + 0% softirq
01-15 16:49:02.436 I/ (2466): dumpmesg > "/data/log/dumpstate_app_anr.log"

我們用自然語(yǔ)言來描述一下日志，這也算是一種能力吧 。
01-15 16:49:02.433 E/ActivityManager(2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)
翻譯：在16:49分2秒433毫秒的時(shí)候 ActivityManager （進(jìn)程號(hào)為2466) 發(fā)生了如下錯(cuò)誤：com.android.mms包下面的.ui.SlideshowActivity 無響應(yīng) 。

01-15 16:49:02.433 E/ActivityManager(2466): Reason: keyDispatchingTimedOut
翻譯：原因 ， keyDispatchingTimeOut - 按鍵分配超時(shí)

01-15 16:49:02.433 E/ActivityManager(2466): Load: 0.6 / 0.61 / 0.42
翻譯：5分鐘，10分鐘，15分鐘內(nèi)的平均負(fù)載分別為：0.6 , 0.61 , 0.42

在這里我們大概知道問題是什么了，結(jié)合我們之前的操作流程，我們知道問題是在點(diǎn)擊按鈕某時(shí)候可能處理不過來按鈕事件，導(dǎo)致超時(shí)無響應(yīng) 。那么現(xiàn)在似乎已經(jīng)可以進(jìn)行工作了 。 我們知道Activity中是通過重載dispatchTouchEvent(MotionEvent ev)來處理點(diǎn)擊屏幕事件 。 然后我們可以順藤摸瓜，一點(diǎn)點(diǎn)分析去查找原因 。 但這樣夠了么 ？
其實(shí)不夠 ， 至少我們不能準(zhǔn)確的知道到底問題在哪兒 ， 只是猜測(cè) ，比如這個(gè)應(yīng)用程序中，我就在順藤摸瓜的時(shí)候發(fā)現(xiàn)了多個(gè)IO操作的地方都在主線程中，可能引起問題，但不好判斷到底是哪個(gè) ，所以我們目前掌握的信息還不夠 。

于是我們?cè)俜治鎏摂M機(jī)信息 ， 搜索“Dalvik Thread”關(guān)鍵詞，快速定位到本應(yīng)用程序的虛擬機(jī)信息日志，如下：
----- pid 2922 at 2011-01-13 13:51:07 -----
Cmd line: com.android.mms

DALVIK THREADS:
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x4001d8d0 self=0xccc8
| sysTid=2922 nice=0 sched=0/0 cgrp=default handle=-1345017808
| schedstat=( 3497492306 15312897923 10358 )
at android.media.MediaPlayer._release(Native Method)
at android.media.MediaPlayer.release(MediaPlayer.java:1206)
at android.widget.VideoView.stopPlayback(VideoView.java:196)
at com.android.mms.ui.SlideView.stopVideo(SlideView.java:640)
at com.android.mms.ui.SlideshowPresenter.presentVideo(SlideshowPresenter.java:443)
at com.android.mms.ui.SlideshowPresenter.presentRegionMedia(SlideshowPresenter.java:219)
at com.android.mms.ui.SlideshowPresenter4.run(SlideshowPresenter.java:516) at android.os.Handler.handleCallback(Handler.java:587) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:123) at android.app.ActivityThread.main(ActivityThread.java:4627) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:521) at com.android.internal.os.ZygoteInitMethodAndArgsCaller.run(ZygoteInit.java:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)

"Binder Thread #3" prio=5 tid=11 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x4837f808 self=0x242280
| sysTid=3239 nice=0 sched=0/0 cgrp=default handle=2341032
| schedstat=( 32410506 932842514 164 )
at dalvik.system.NativeStart.run(Native Method)

"AsyncQueryWorker" prio=5 tid=9 WAIT
| group="main" sCount=1 dsCount=0 s=N obj=0x482f4b80 self=0x253e10
| sysTid=3236 nice=0 sched=0/0 cgrp=default handle=2432120
| schedstat=( 3225061 26561350 27 )
at java.lang.Object.wait(Native Method)
-waiting on <0x482f4da8> (a android.os.MessageQueue)
at java.lang.Object.wait(Object.java:288)
at android.os.MessageQueue.next(MessageQueue.java:146)
at android.os.Looper.loop(Looper.java:110)
at android.os.HandlerThread.run(HandlerThread.java:60)

"Thread-9" prio=5 tid=8 WAIT
| group="main" sCount=1 dsCount=0 s=N obj=0x4836e2b0 self=0x25af70
| sysTid=2929 nice=0 sched=0/0 cgrp=default handle=2370896
| schedstat=( 130248 4389035 2 )
at java.lang.Object.wait(Native Method)
-waiting on <0x4836e240> (a java.util.ArrayList)
at java.lang.Object.wait(Object.java:288)
at com.android.mms.data.ContactContactsCacheTaskStack$1.run(Contact.java:488)
at java.lang.Thread.run(Thread.java:1096)

"Binder Thread #2" prio=5 tid=7 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x482f8ca0 self=0x130fd0
| sysTid=2928 nice=0 sched=0/0 cgrp=default handle=1215968
| schedstat=( 40610049 1837703846 195 )
at dalvik.system.NativeStart.run(Native Method)

"Binder Thread #1" prio=5 tid=6 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x482f4a78 self=0x128a50
| sysTid=2927 nice=0 sched=0/0 cgrp=default handle=1201352
| schedstat=( 40928066 928867585 190 )
at dalvik.system.NativeStart.run(Native Method)

"Compiler" daemon prio=5 tid=5 VMWAIT
| group="system" sCount=1 dsCount=0 s=N obj=0x482f1348 self=0x118960
| sysTid=2926 nice=0 sched=0/0 cgrp=default handle=1149216
| schedstat=( 753021350 3774113668 6686 )
at dalvik.system.NativeStart.run(Native Method)

"JDWP" daemon prio=5 tid=4 VMWAIT
| group="system" sCount=1 dsCount=0 s=N obj=0x482f12a0 self=0x132940
| sysTid=2925 nice=0 sched=0/0 cgrp=default handle=1255680
| schedstat=( 2827103 29553323 19 )
at dalvik.system.NativeStart.run(Native Method)

"Signal Catcher" daemon prio=5 tid=3 RUNNABLE
| group="system" sCount=0 dsCount=0 s=N obj=0x482f11e8 self=0x135988
| sysTid=2924 nice=0 sched=0/0 cgrp=default handle=1173688
| schedstat=( 11793815 12456169 7 )
at dalvik.system.NativeStart.run(Native Method)

"HeapWorker" daemon prio=5 tid=2 VMWAIT
| group="system" sCount=1 dsCount=0 s=N obj=0x45496028 self=0x135848
| sysTid=2923 nice=0 sched=0/0 cgrp=default handle=1222608
| schedstat=( 79049792 1520840200 95 )
at dalvik.system.NativeStart.run(Native Method)

----- end 2922 -----

每一段都是一個(gè)線程 ，當(dāng)然我們還是看線程號(hào)為1的主線程了。通過分析發(fā)現(xiàn)關(guān)鍵問題是這樣：
at com.android.mms.ui.SlideshowPresenter$3.run(SlideshowPresenter.java:531)
定位到代碼：

mHandler.post(new Runnable() {
                    public void run() {
                        try {
                            presentRegionMedia(view, (RegionMediaModel) model, dataChanged);
                        } catch (OMADRMException e) {
                            Log.e(TAG, e.getMessage(), e);
                            Toast.makeText(mContext,mContext.getString(R.string.insufficient_drm_rights),
                                    Toast.LENGTH_SHORT).show();
                        } catch (IOException e){
                            Log.e(TAG, e.getMessage(), e);
                            Toast.makeText(mContext, mContext.getString(R.string.insufficient_drm_rights), Toast.LENGTH_SHORT).show();
                        }
                    }

很清楚了， Handler.post 方法之后執(zhí)行時(shí)間太長(zhǎng)的問題 。 繼續(xù)看presentRegionMedia(view, (RegionMediaModel) model, dataChanged);方法 ， 發(fā)現(xiàn)最終是調(diào)用的framework 中MediaPlayer.stop方法 。
至此，我們的日志分析算是告一段落 。 可以開始思考解決辦法了。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 227,837評(píng)論 6贊 531
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,196評(píng)論 3贊 414
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
    開封第一講書人閱讀 175,688評(píng)論 0贊 373
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長(zhǎng)。 經(jīng)常有香客問我，道長(zhǎng)，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 62,654評(píng)論 1贊 309
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 71,456評(píng)論 6贊 406
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 54,955評(píng)論 1贊 321
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音，去河邊找鬼。 笑死，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,044評(píng)論 3贊 440
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長(zhǎng)吁一口氣：“原來是場(chǎng)噩夢(mèng)啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 42,195評(píng)論 0贊 287
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個(gè)月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 48,725評(píng)論 1贊 333
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,608評(píng)論 3贊 354
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,802評(píng)論 1贊 369
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 38,318評(píng)論 5贊 358
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,048評(píng)論 3贊 347
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,422評(píng)論 0贊 26
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,673評(píng)論 1贊 281
  • 情欲美人皮
    我被黑心中介騙來泰國(guó)打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,424評(píng)論 3贊 390
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像，于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,762評(píng)論 2贊 372

推薦閱讀更多精彩內(nèi)容

  • ANR問題，相信是每位開發(fā)日常都會(huì)遇到的問題，對(duì)于這類問題的分析，按照官方的推薦，或網(wǎng)絡(luò)博客的總結(jié)思路能解決一定的...
    tiger桂閱讀 17,967評(píng)論 5贊 28
  • Android 自定義View的各種姿勢(shì)1 Activity的顯示之ViewRootImpl詳解 Activity...
    passiontim閱讀 172,607評(píng)論 25贊 708
  • 什么是ANR ANR(Application Not Responding)就是應(yīng)用在規(guī)定的時(shí)間內(nèi)沒有響應(yīng)用戶輸入...
    lbtrace閱讀 3,403評(píng)論 3贊 9
  • Log 在Android中的地位非常重要，要是作為一個(gè)android程序員不能過分析log這關(guān)，算是android...
    雷哥說閱讀 948評(píng)論 0贊 6
  • 作者簡(jiǎn)介： 唐媽，簡(jiǎn)書簽約作者，擅長(zhǎng)用流暢的文字講述溫暖的故事，包括但不陷入都市仙俠魔幻，無異能，不善言辭，但是有...
    唐媽閱讀 8,132評(píng)論 5贊 59