稳定性分析4 看进程号
Watchdog分析方法
Andriod的system_server进程本身带有watchdog机制来监控应用程序异常，dalvik虚拟机本身也会对应用程序死锁或死循环进行检测，当应用程序超时无响应，android会将该进程杀死并在/data/anr目录下面生成trace.txt文件记录这次异常信息。亦可调用android工具bugreport来导出系统的所有相关信息。
系统发生watchdog异常时，adb log中一般都有以下信息
02-21 14:58:24.619 W/Watchdog( 162): *** WATCHDOG KILLING SYSTEM PROCESS: null
并且在将系统的调用堆栈信息或者其他信息保存到dropbox目录和trace.txt目录。插个题外话，
应用在发生anr时会生成调用栈信息保存在data/anr/trace.txt文件中，但该文件保存的信息包括且不局限于anr log。因此我们在log中如果看到该log 文件的生成，不要轻易断定系统发生了anr。
对watchdog信息的分析需要关注发生异常的时间点，即时间点和重启发生的时间必须要一致，否则就是在一个错误的信息上进行分析，判断出现失误且浪费时间和精力。
03-19 03:52:49.348 E/AndroidRuntime( 2413): *** FATAL EXCEPTION IN SYSTEM PROCESS: TransferPipe
03-19 03:52:49.348 E/AndroidRuntime( 2413): java.lang.NullPointerException
03-19 03:52:49.348 E/AndroidRuntime( 2413): at com.android.server.am.TransferPipe.run(TransferPipe.java:184)
03-19 03:52:49.348 E/AndroidRuntime( 2413): at java.lang.Thread.run(Thread.java:856)
03-19 03:53:00.585 I/Watchdog_N( 2413): dumpKernelStacks
03-19 03:53:00.812 I/Process ( 2413): Sending signal. PID: 2413 SIG: 9
03-19 03:53:00.812 W/Watchdog( 2413): *** WATCHDOG KILLING SYSTEM PROCESS: null
03-19 03:53:11.655 I/ServiceManager( 1687): service ‘entropy’ died
03-19 03:53:11.655 I/ServiceManager( 1687): service ‘wifi’ died
首先根据adb log中的信息，可以判断出在03-19 03:53:00时间点单本发生了一次系统重启。并且要记住此时System Server进程的PID是2413.
我们再来分析System Server这个进程详细的堆栈调用关系，堆栈调用关系有可能存在
data/anr目录下的trace文件中，也有可能存在data/system/dropbox目录下，该目录下面。
之所以发生Watchdog异常，是因为几个最主要的服务发生了阻塞（窗口服务、包管理服务、Activity服务、输入输出服务等），系统进行保护性重启，有了阻塞时的堆栈调用信息，就能尝试找出引入连锁阻塞的最底层原因。
持续停留在菊花界面的原因有两个，一个是System Serer服务异常导致Zygote进程不断退出后重新启动或者其他重要系统级服务不断异常退出后重启，造成系统一直停留在开机动画界面，这种情况比较好定位，因为有很明显的错误信息，根据该错误信息修改即可，并且根据经验，此类问题一般为自修改引入，可通过烧不同时期的每日构建版本进行排查。另外一种比较特殊，即系统adb log没有任何新增信息输出，也没有明显异常，但是系统一直停留在菊花界面。
针对后种情况的出现，刚开始分析定位时百思不得其解，因为按照Android的默认处理机制，如果是System Server进程中的某些重要线程服务发生阻塞，WatchDog机制是能够保证系统进行保护性重启的，但是为什么系统一直停留在菊花界面，没有新增adb log输出，系统也不重启呢？后来通过增加log定位发现，WatchDog的初始化启动比较靠后，System Server服务初始化完所有系统重要服务时，WatchDog机制才会启动，而如果在此机制没有启动前，System Server就发生了阻塞，此时就悲剧了。系统不会重启，且一直停留在菊花界面，表现形式为系统不能正常开机。
此类问题的定位方法可以采取如下方式，强制使用如下命令生成对应进程的堆栈，然后对堆栈调用进行分析，找到系统阻塞点。
日记本
相关推荐
EasyCode(代码神器)
阅读 3391
免费报名>>中欧MBA公开课
广告
NurVideoPlayer 视频播放器,使用特别简单
阅读 773
Android布局优化（三）使用AsyncLayoutInflater异步加载布局
阅读 967
【Android开发】自定义控件——带返回键标题栏
阅读 310
