Android -如何调查ANR？
有没有办法找出我的应用程序在哪里抛出了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方法。
回答 8
Stack Overflow用户
发布于 2009-04-01 20:59:06
当某个长操作在"main“线程中发生时，就会发生ANR。这是事件循环线程，如果它很忙，Android将无法在应用程序中处理任何进一步的GUI事件，从而抛出一个ANR对话框。
现在，在您发布的跟踪中，主线程似乎做得很好，没有问题。它在MessageQueue中处于空闲状态，等待另一条消息进入。在您的例子中，ANR可能是一个较长的操作，而不是永久阻塞线程的操作，所以事件线程在操作完成后恢复，您的跟踪在ANR之后进行。
如果是永久阻塞(例如死锁获取一些锁)，那么检测ANR发生的位置很容易，但如果只是暂时的延迟，则很难。首先，检查你的代码，寻找不可靠的地方和长时间运行的操作。示例可以包括使用套接字、锁、线程休眠和来自事件线程内的其他阻塞操作。您应该确保所有这些都发生在单独的线程中。如果没有问题，请使用DDMS并启用线程视图。这将显示应用程序中的所有线程，类似于您拥有的跟踪。重现ANR，同时刷新主线程。这应该会准确地向您显示ANR发生时的情况
Stack Overflow用户
发布于 2014-08-08 15:14:57
我在过去的几个月里一直在学习android，所以我远不是一个专家，但我对ANR的文档真的很失望。
大多数建议似乎都是为了避免它们或通过盲目查看您的代码来修复它们，这很好，但我在分析跟踪方面找不到任何东西。
在ANR日志中，有三件事是你真正需要注意的。
1)死锁:当一个线程处于等待状态时，你可以通过查看详细信息来找出它是谁的"heldby=“。大多数时候，它会被自己持有，但如果它被另一个线程持有，这很可能是一个危险的信号。去看看那条线，看看它是由什么支撑的。您可能会发现一个循环，这是出了问题的明确信号。这是非常罕见的，但这是第一点，因为当它发生时，这是一场噩梦
2)主线程正在等待:如果您的主线程处于等待状态，请检查是否被其他线程占用。这不应该发生，因为你的UI线程不应该被后台线程持有。
这两种情况都意味着你需要大量地修改你的代码。
3)主线程上的繁重操作:这是and最常见的原因，但有时也是较难找到和修复的原因之一。查看主线程的详细信息。向下滚动堆栈跟踪，直到看到(从应用程序中)识别出的类。查看跟踪中的方法，找出是否在这些地方进行网络调用、db调用等。
最后，我为厚颜无耻地插入我自己的代码道歉，你可以使用我在https://github.com/HarshEvilGeek/Android-Log-Analyzer编写的python日志分析器，它将检查你的日志文件，打开ANR文件，找到死锁，找到等待的主线程，在你的代理日志中找到未捕获的异常，并以一种相对容易阅读的方式在屏幕上打印出来。阅读ReadMe文件(我将添加该文件)以了解如何使用它。在过去的一周里，它帮了我很多忙！
Stack Overflow用户
发布于 2011-02-19 04:26:55
每当您分析计时问题时，调试通常没有帮助，因为在断点处冻结应用程序将使问题消失。
最好的办法是在应用程序的不同线程和回调中插入大量日志记录调用(Log.XXX())，看看延迟在哪里。如果你需要一个堆栈跟踪，创建一个新的异常(只实例化一个)并记录它。
https://stackoverflow.com/questions/704311
复制相似问题