Android System ANR/Force Close Analysis
ANR
1)what triggers ANR
KeydispatchTimeout 5s
broadcastTimeout FG 10s BG 60:
ServiceTimeout 20s
2) 查看./data/anr/traces.txt
分析步骤:
1)通过 logcat -v threadtime& 拿到logcat.txt和./data/anr/traces.txt 这一时刻的callstack.
在logcat.txt中ANR 关键字.I Process : Sending signal. PID: XXX SIG: 3 就是此时刻dump PID:XXX 到traces.txt的call stack.
首先判断是CPU占用率,iowait ?再判断是否是主线程是否BLock住.
如果是主线程BLOCK住.查第一次Wrote stack traces to '/data/anr/traces.txt'前5s (keyDispathTimeout )各个主进程在做什么,然后结合trace.txt看是卡那一步/后者耗在哪里.
2)
Q&A
1)trace.txt文件具体解释.
//参考http://blog.csdn.net/rambo2188/article/details/7017241
它的输出格式如下：
[plain] view plaincopyprint?
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x400246a0 self=0x12770
| sysTid=503 nice=0 sched=0/0 cgrp=default handle=-1342909272
| schedstat=( 15165039025 12197235258 23068 ) utm=182 stm=1334 core=0
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:119)
at android.os.Looper.loop(Looper.java:122)
at android.app.ActivityThread.main(ActivityThread.java:4134)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:491)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
at dalvik.system.NativeStart.main(Native Method)
至此， 我们可以很清楚的 解析 trace文件中 thread信息的含义了：
1. 第一行是 固定的头, 指明下面的都是 当前运行的 dvm thread ：“DALVIK THREADS:”
2. 第二行输出的是该 进程里各种线程互斥量的值。（具体的互斥量的作用在 dalvik 线程一章 单独陈述）
3. 第三行输出分别是 线程的名字（“main”），线程优先级（“prio=5”），线程id（“tid=1”） 以及线程的 类型（“NATIVE”）
4. 第四行分别是线程所述的线程组 （“main”），线程被正常挂起的次处（“sCount=1”），线程因调试而挂起次数（”dsCount=0“），当前线程所关联的java线程对象（”obj=0x400246a0“）以及该线程本身的地址（“self=0x12770”）。
5. 第五行 显示 线程调度信息。 分别是该线程在linux系统下得本地线程id （“ sysTid=503”），线程的调度有优先级（“nice=0”），调度策略（sched=0/0），优先组属（“cgrp=default”）以及 处理函数地址（“handle=-1342909272”）
6 第六行 显示更多该线程当前上下文，分别是 调度状态（从 /proc/[pid]/task/[tid]/schedstat读出）（“schedstat=( 15165039025 12197235258 23068 )”），以及该线程运行信息 ，它们是 线程用户态下使用的时间值(单位是jiffies）（“utm=182”）， 内核态下得调度时间值（“stm=1334”），以及最后运行改线程的cup标识（“core=0”）；
7.后面几行输出 该线程 调用栈。
有了以上信息，我们便更容易分析出app是为什么被异常终止的了。我们会在单独的一章分析， 怎样利用trace文件里的信息寻找app异常终止的原因。敬请期待。
2)process 都是Block 在主线程上吗?