ANR的log如何分析才能快速找到问题的原因？

Question

本帖最后由 ameyume 于 2011-08-24 09:28:13 编辑

Answer 1

Your activity took to long to say to the Android OS 'hey i'm still alive'! (This is what the UI thread does).http://developer.android.com/guide/practices/design/responsiveness.htmlBasically if you make the UI thread do some complex task it's too busy doing your task to tell the OS that it is still 'alive'.http://developer.android.com/resources/articles/painless-threading.htmlYou should move your XML Parsing code to another thread, then use a callback to tell the UI thread you have finished and to do something with the result.http://developer.android.com/resources/articles/timed-ui-updates.html

Answer 2

    StrictMode is most commonly used to catch accidental disk or network access on the application's main thread, where UI operations are received and animations take place. By keeping your application's main thread responsive, you also prevent ANR dialogs from being shown to users.public void onCreate() {
    StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                           .detectAll()
                           .penaltyLog()
                           .penaltyDeath()
                           .build());
    super.onCreate();
}    using penaltyLog() you can watch the output of adb logcat while you use your application to see the violations as they happen.

Answer 3

这个讨论的话题真好！！
就像文章中所总结的，ANR的分类：
1.应用程序错误
2.Java application Hang
3.Dalvik/ Core Libraries的错误
4.kernel错误
5.Modem的问题各种ANR还需要具体情况具体分析，并没有一种通用的方法可以快速定位，唯一通用的办法就是logcat和dmesg了，这也是解决bug过程中必需的……希望有更多人参与讨论，针对不同模块，分享经验。

Answer 4

    我一般是ANR以后，用DDMS连上去，调试查看主线程在哪里死循环

Answer 5

没什么啊 分享经验 共同进步  DDMS连上查看死在哪里 的确是基本思路呀 

Answer 6

DDMS + 人工追踪代码飘过调试方面还是个新手，正在寻求比较好的方法
飘啊飘

Answer 7

logcat while you use your application

Answer 8

bugreport中一般都能够找到是死在哪个类哪个方法多少行.

Answer 9

底层的anr就不太好查，我目前主要还是看重现看log，只看测试提供的log有时候还是摸不着头脑。
今天一直忙，没来得及上来看。
多谢各位捧场，还被推荐，凡是回复的通通有分

Answer 10

这个需要用addr2line命令查看编译出来的symbol下的so代码行数。

Answer 11

http://blog.csdn.net/yiyaaixuexi/article/details/6716884

Answer 12

根据log和dmesg大致确定问题的位置，然后从上层一直追下去。在可能出现问题的地方加入LOG调试，可以借助SDK TOOLS。
方法大致是这样，但是本人很菜，还没有什么具体的经验~

Answer 13

有一个关于Android方面的群就好了 大家平时可以一起讨论

Answer 14

直接看log就差不多能定位了 

Answer 15

其实/data/anr/trace.txt这个堆栈还是很有用的，只要系统出现ANR一次，就会往堆栈的文件里面写进去一次，无论是app的ANR还是service的timeout，都会有记录，不过唯一的缺点就是他是java的堆栈，只能跟踪到java，JNI甚至到底层出的问题导致java出现ANR，这个是需要自己深度往下跟踪，这个trace只能起到切入点的作用了。最近靠trace.txt找到了开机有非常小的几率在开机动画的时候systemserver被kill的问题，就是在SurfaceFlinger的JNI里面出现的死锁导致systemServer的timeout，一点点经验，分享一下。

Answer 16

mkdir /data/anr
kill -3 youapp_pidsee /data/anr/traces.txt
or kill -3 -zygote_pid
you'll get some more