Camera ANR分析案例

获取日志

AP Log:
/sdcard/mtklog/mobilelog/APLog_XXXXX

/sdcard/debuglogger/mobilelog/APLog_XXXXX

db:

/data/aee_exp

如果db 打包没完成,trace 完成了 然后导出手机中的anr日志 /data/anr/.

1.拿到日志先 搜索

ANR in 包命(例com.mediatek.camera)  找到对应的PID  根据PID去看堆栈信息

如有 就会出现Reason: Input dispatching timed out.......内容

然后导出手机中的anr日志 

adb pull /data/anr/ . 

                                图1

ANR分析流程

 APP空闲:

检查Callstack,查看 main thread 的callstack 停在nativePollOnce(FROM_SWT_JBT_TRACES)

No focus Window ANR Check point:

检查 activity onResume时间点(此时activity能被看到),如果发生ANR时onResume还未完成,归类为APP related Issue

Log分析步骤

1.确认ANR发生时间节点

2.从ANR process main thread 查看 callstack

3.对比上图确认问题

4.定位问题之后具体问题具体分析

常见的ANR有

1.等锁

线程状态为 blocked ,通过关键字 held by 进一步确认哪个线程拿住了锁 

解决办法 检查code 逻辑进行解锁

线程为 waiting ,表示当前线程需要另外一个线程来notify() 需要根据 callstack 结合code来做分析以找到拿住锁的线程 ,如果很多线程持有一把锁,可能产生资源竞争,导致目标线程拿不到锁

导出的文件会有一些ANR日志    然后对应每个文件里面取搜 需要的包名 这里拿com.mediatek.camera 举例

2.binder sever 卡主

线程状态为 native ,且含有callstack:IPCThreadState::waitForResponse-->IPCThreadState::takeWaitDriver

表示卡在binder 对端,找对端线程的堆栈(callstack) 看卡哪里了

找对端的方法有

        1)根据binder 线程 的sysTid 在SYS_BINDER_INFO/SWT_JBT_TRACES/kernel_log中查找binder 的通信对端接口 关键字为 outgoing transaction

        2)在SYS_PROCESSES_AND_THREADS 通过对端sysTid查找 process name

        3)如果是Monkey 不用太过于关注这个 严重情况除外

3.Native 方法太过耗时

线程状态为 Native ,根据callstack 找到 哪个方法耗时了  找到对应的负责人 

4.zygote fork 进程卡主

线程状态为Native ,确认堆栈信息中Process.zygoteSendArgsAndGetResult

一般情况都是memory 引起 查看是否是内存不足、内存泄漏

5.Dump 时间过长

1.有ANR 发生 ANR in ... 并且线程正在 dump 

通过 callstack :appNotResponding / dumpStackTraces

2.从SYS_ANDROID_LOG 中确认 哪个线程dump时间太长

3.搜索关键字dumpStackTraces process 来确认发生ANR时所有的dump

4.确认 上下进程时间差是否大于60s 或者所有进程的dump时间总和远大于60s

5.确认进程后 具体分析code 处理

猜你喜欢

转载自blog.csdn.net/I_am_a_loser/article/details/127090111