判断是什么类型的死机重启，即死机重启大概是由系统应用、Framework框架、JNI层、驱动层还是更底层引起的，是我们研发人员的主要工作。也是死机重启问题分析的难点。
一般来说，在从测试组拿到一个发生过死机重启问题单或者单板时，首先需要判断这是一个何种类型的死机重启问题，一般可以按照如下的流程来进行：
检查apanic信息：一般来说如果在发生死机的时间段上有apanic信息存在，那代表这就是内核出现的异常，这个信息在bugreport的apanic_console和dropbox目录下都会有记录。
通过bugreport中的dropbox信息来判断在发生死机的时间段上是否有system_server_watchdog或者system_server_crash等信息存在，如果存在，那么基本可以判断该重启是一个android系统重启，应该从这些信息来入手进行分析。
当apanic和dropbox信息都没有的情况下，而在测试人员描述的重启发生的时间点上，的确又存在一次BOOT事件的时候，同时从LOG信息中在那个时间点上也的确看不出什么问题的时候，要么只能怀疑问题是出现在modem侧，或者Log抓取有遗漏，需要测试协助帮忙继续复现或者改进Log抓取工具。
如何识别有效log呢，一个最重要的切入点是要保证异常发生的时间与异常Log信息能够对应上，对于一些有时间标识的log，要做到这一点难度不大，例如adb log，但是对于一些没有时间标识且相对陌生的log，要做到这一点难度较大，一个行之有效的方法就是使用进程ID和线程ID。通常情况下系统重启后相应进程的ID以及进程包括的大量线程ID会发生变化，如果没有时间标识的异常log能够与有时间标识的异常log中相关的异常进程ID以及线程ID能够对应上，则基本可以断定已经找到了问题跟因。另外也强烈建议测试同事在进行测试之前对单本中的data分区log事先进行清除或者整机恢复出厂设置后再测试，这样可以认为的减少无效Log信息对问题定位的干扰。
结合实际的异常Log分析，大家在进行异常排查的时候，可以参考下面的关键字排序搜索，以便能够更快的找到定位信息。
对于android应用程序，一般在如下几种情况会产生异常记录信息：
程序异常退出，uncaused exception；
程序强制关闭，Force Closed (简称FC)；
程序无响应，Application No Response（简称ANR)，一般主线程超过5秒没有处理就会ANR。
如果是ANR问题，需要结合trace信息找到具体应用对应的堆栈调用信息，即可找出耗时操作或者发生阻塞所对应的代码。如果是ForceClosed和其它异常退出信息，则搜索"Fatal"关键词，可以快速定位到关键事件信息。通常关键字搜索的优先级顺序为
fatal - panic - Watchdog - Shutting down VM - AndroidRuntime - error - exception - reboot
日记本
相关推荐
2019年鸿洋大神最新整理一线互联网公司Android中高级面试题总结（附答案解析）
阅读 1408
免费报名>>中欧MBA公开课
广告
太恐怖了！移动开发APP 可视化埋点技术原理竟然是这样的？！
阅读 1048
康熙做过一次秘密“人体试验”，30个宫女死了4个，称试验成功
阅读 58661
我和7个PUA导师聊了一宿，总结出祸害女生有这些套路
阅读 22867
