有没有一种方法可以找出我的应用程序在哪里抛出了ANR(应用程序无响应)。我查看了/data中的traces.txt文件，并看到了我的应用程序的跟踪。这就是我在跟踪中看到的。
DALVIK THREADS:
"main" prio=5 tid=3 TIMED_WAIT
| group="main" sCount=1 dsCount=0 s=0 obj=0x400143a8
| sysTid=691 nice=0 sched=0/0 handle=-1091117924
at java.lang.Object.wait(Native Method)
- waiting on <0x1cd570> (a android.os.MessageQueue)
at java.lang.Object.wait(Object.java:195)
at android.os.MessageQueue.next(MessageQueue.java:144)
at android.os.Looper.loop(Looper.java:110)
at android.app.ActivityThread.main(ActivityThread.java:3742)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:739)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:497)
at dalvik.system.NativeStart.main(Native Method)
"Binder Thread #3" prio=5 tid=15 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x434e7758
| sysTid=734 nice=0 sched=0/0 handle=1733632
at dalvik.system.NativeStart.run(Native Method)
"Binder Thread #2" prio=5 tid=13 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x433af808
| sysTid=696 nice=0 sched=0/0 handle=1369840
at dalvik.system.NativeStart.run(Native Method)
"Binder Thread #1" prio=5 tid=11 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x433aca10
| sysTid=695 nice=0 sched=0/0 handle=1367448
at dalvik.system.NativeStart.run(Native Method)
"JDWP" daemon prio=5 tid=9 VMWAIT
| group="system" sCount=1 dsCount=0 s=0 obj=0x433ac2a0
| sysTid=694 nice=0 sched=0/0 handle=1367136
at dalvik.system.NativeStart.run(Native Method)
"Signal Catcher" daemon prio=5 tid=7 RUNNABLE
| group="system" sCount=0 dsCount=0 s=0 obj=0x433ac1e8
| sysTid=693 nice=0 sched=0/0 handle=1366712
at dalvik.system.NativeStart.run(Native Method)
"HeapWorker" daemon prio=5 tid=5 VMWAIT
| group="system" sCount=1 dsCount=0 s=0 obj=0x4253ef88
| sysTid=692 nice=0 sched=0/0 handle=1366472
at dalvik.system.NativeStart.run(Native Method)
----- end 691 -----
我如何找出问题所在？跟踪中的方法都是SDK方法。
谢谢。
最佳答案
当在“主”线程中进行一些长时间的操作时，会发生ANR。这是事件循环线程，如果繁忙，则Android无法处理应用程序中的任何其他GUI事件，从而引发ANR对话框。
现在，在您发布的跟踪中，主线程似乎运行良好，没有问题。它在MessageQueue中处于空闲状态，等待另一条消息进入。在您的情况下，ANR可能是一个较长的操作，而不是永久性地阻塞线程的操作，因此事件线程在操作完成后恢复，并且您的跟踪经历了在ANR之后。
如果它是一个永久性的块(例如，死锁获取了一些锁)，则检测ANR发生的位置很容易，但是如果只是一个暂时的延迟，则很难检测。首先，检查您的代码，寻找脆弱的地方和长期运行的操作。示例可能包括使用事件线程内部的套接字，锁，线程 sleep 和其他阻止操作。您应该确保所有这些操作都在单独的线程中进行。如果似乎没有问题，请使用DDMS并启用线程 View 。这显示了应用程序中的所有线程，与您拥有的跟踪类似。再现ANR，并同时刷新主线程。那应该准确地告诉您ANR发生了什么
关于android - Android-如何调查ANR？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/704311/