标签：android4.4 watchdog 看门狗 service
Android 软watchdog机制主要功能集中在两个层面：
1），监听系统的reboot广播；
2），监听相关service是否死锁。
首先，从代码看，watchdog是由SystemServer.java启动：
这几行代码首先是初始化了watchdog，
添加UIThread，FgThread，IoThread，还有当前new Watchdog时候的主线程，其实就是System_server主线程。
添加至mHandlerCheckers这个MonitorList中，接下来看init接口：
这个接口里边将需要watchdog监听的几个service赋值过来，同时注册接收reboot的广播。
随后SystemServer通过Watchdog.getInstance().start();调用其run方法，开始循环侦听功能。
run()方法中有一个无限循环，每次循环中主要做三件事：
1.
publicvoidscheduleCheckLocked() {
}
HandlerChecker对象即要监控服务，也要监控某个线程。所以上面的代码先判断mMonitors的size是否为0。如果为0，说明这个HandlerChecker没有监控服务，这时如果被监控线程的消息队列处于空闲状态（调用isIdling()检查），则说明线程运行良好，把mCompleted设为true后就可以返回了。否则先把mCompleted设为false，然后记录消息开始发送的时间到变量mStartTime中，最后调用postAtFrontOfQueue()方法给被监控的线程发送一个消息。此时在Handler.java的
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if(mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
这个消息的处理方法是HandlerChecker类的方法run()，代码如下：
public void run() {
}
如果消息处理方法run()能够被执行，说明受监控的线程本身没有问题。但是还需要检查被监控服务的状态。检查是通过调用服务中实现的monitor()方法来完成的。通常monitor()方法的实现是获取服务中的锁，如果不能得到，线程就会被挂起，这样mCompleted的值就不能被置成true了。
mCompleted的值为true，表明HandlerChecker对象监控的线程或服务正常。否则就可能有问题。是否真有问题还要通过等待的时间是否超过规定时间来判断。
moninor()方法的实现通常如下：
public void monitor() {
}
2.
3.
前面调用了方法evaluateCheckerCompletio
privateintevaluateCheckerCompletio
}
getCompletionStateLocked
public int getCompletionStateLocked
}
本文只对流程做了相对简单的分析，抛开监听reboot广播不说，在我看来，监听线程就是定时分别尝试获取一次添加到watchdog monitorcheckerList中的service的monitor()接口（尝试获取一次service内部的锁），如果成功获取并释放，则说明service未出现死锁的状况，则一段时间后继续该操作；如若不然，即获取service内相关的锁失败，则说明有service可能处于死锁状态，从而Watchdog线程杀死SystemServer进程。SystemServer监控重要service，重要service hang则SystemServer死，SystemServer死则Zygote监控到，Zygote也死并且杀死整个Java世界，Zygote死则init监控到，init重新启动Zygote，之后SystemServer、service又进入重生过程。
版权声明：本文为博主原创文章，未经博主允许不得转载。
标签：android4.4 watchdog 看门狗 service
原文地址：http://blog.csdn.net/dkbdkbdkb/article/details/48023793
