Android 4.4 Watchdog机制

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. 调用scheduleCheckLocked()方法给所有受监控的线程发送消息。scheduleCheckLocked()方法的代码如下

publicvoidscheduleCheckLocked() {

if(mMonitors.size() == 0 &&mHandler.getLooper().isIdling()) {

mCompleted= true;

return;

}

if(!mCompleted) {

return;

}

mCompleted= false;

mCurrentMonitor= null;

mStartTime= SystemClock.uptimeMillis();

mHandler.postAtFrontOfQueue(this);//给监视的线程发送消息

}



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() {

finalint size = mMonitors.size();

for(int i = 0 ; i < size ; i++) {

synchronized(Watchdog.this) {

mCurrentMonitor= mMonitors.get(i);

}

mCurrentMonitor.monitor();

}

synchronized(Watchdog.this) {

mCompleted= true;

mCurrentMonitor= null;

}

}

如果消息处理方法run()能够被执行，说明受监控的线程本身没有问题。但是还需要检查被监控服务的状态。检查是通过调用服务中实现的monitor()方法来完成的。通常monitor()方法的实现是获取服务中的锁，如果不能得到，线程就会被挂起，这样mCompleted的值就不能被置成true了。

mCompleted的值为true，表明HandlerChecker对象监控的线程或服务正常。否则就可能有问题。是否真有问题还要通过等待的时间是否超过规定时间来判断。

moninor()方法的实现通常如下：

public void monitor() {

synchronized(mLock) {

}

}

2. 给受监控的线程发送完消息后，调用wait()方法让WatchDog线程睡眠一段时间。

3. 逐个检查是否有线程或服务出问题了，一旦发现问题，马上杀死进程。

前面调用了方法evaluateCheckerCompletionLocked()来检查线程或服务是否有问题。evaluateCheckerCompletionLocked()方法的代码如下：

privateintevaluateCheckerCompletionLocked() {

intstate = COMPLETED;

for(int i=0; i < mHandlerCheckers.size(); i++) {

HandlerCheckerhc =mHandlerCheckers.get(i);

state= Math.max(state,hc.getCompletionStateLocked());

}

returnstate;

}

getCompletionStateLocked()函数根据等待时间来确认返回HandlerChecker对象的状态，代码如下：

public int getCompletionStateLocked() {

if(mCompleted) {

returnCOMPLETED;

}else {

longlatency = SystemClock.uptimeMillis() -mStartTime;

if(latency < mWaitMax/2) {

returnWAITING;

}else if (latency < mWaitMax) {

returnWAITED_HALF;

}

}

returnOVERDUE;

}

本文只对流程做了相对简单的分析，抛开监听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又进入重生过程。