SystemServer中的WatchDog
新书上市《深入解析Android 5.0系统》
以下内容节选自本书
对手机系统而言，因为肩负着接听电话和接收短信的“重任”，所以被寄予7x24小时正常工作的希望。但是基于成本，普通的手机系统很难做到完全不出故障。但是大部分的故障都会做重启后消失，不会影响继续使用。所以简单的办法是，如果检测到系统不正常了，将设备重新启动，这样用户就能继续使用了。那么如何才能判断系统是否正常呢。通常的做法是在设备中增加一个硬件看门狗，软件系统必须定时的向看门狗硬件中写值来表示自己没出故障（俗称“喂狗”），否则超过了规定的时间看门狗就会重新启动设备。在Init进程一章中我们介绍了watchdogd守护进程，这个守护进程就是用来喂硬件看门狗的。
硬件看门狗的问题是它的功能比较单一，只能监控整个系统。早期的手机操作系统大多是单任务的，硬件看门狗勉强能胜任。Android的SystemServer是一个非常复杂的进程，里面运行的服务超过五十种，是最可能出问题的进程，因此有必要对SystemServer中运行的各种线程实施监控。但是如果使用硬件看门狗的工作方式，每个线程隔一段时间去喂狗，不但非常浪费CPU，而且会导致程序设计更加复杂。因此Android开发了WatchDog类作为软件看门狗来监控SystemServer中的线程。一旦发现问题，WatchDog会杀死SystemServer进程。
SystemServer的父进程Zygote接收到SystemServer的死亡信号后，会杀死自己。Zygote进程死亡的信号传递到Init进程后，Init进程会杀死Zygote进程所有的子进程并重启Zygote。这样整个手机相当于重启一遍。通常SystemServer出现问题和kernel并没有关系，所以这种“软重启”大部分时候都能够解决问题。而且这种“软重启”的速度更快，对用户的影响也更小。
运行在Binder线程中的方法如果需要使用了全局的资源，就必须建立临界区来实施保护。通常的做法是使用synchronized关键字。例如：
synchronized (mLock) {
......
}
这样，我们可以通过锁mLock被持有的时间来判断服务是否正常。
而判断一个线程是否正常的方法是给这个线程发送消息，如果消息不能在规定的时间内得到处理就表明线程出问题了。
WatchDog运行在一个单独的线程中，它的线程执行方法run()的代码如下：
1. public void run() {
2. booleanwaitedHalf = false;
3. while(true) {
4. finalArrayList blockedCheckers;
5. finalString subject;
6. finalboolean allowRestart;
7. synchronized(this) {
8. longtimeout = CHECK_INTERVAL;
9. //给监控的线程发送消息
10. for(int i=0; i
11. HandlerCheckerhc = mHandlerCheckers.get(i);
12. hc.scheduleCheckLocked();
13. }
14. //睡眠一段时间
15. longstart = SystemClock.uptimeMillis();
16. while(timeout > 0) {
17. try{
18. wait(timeout);
19. }catch (InterruptedException e) {
20. Log.wtf(TAG,e);
21. }
22. timeout= CHECK_INTERVAL - (SystemClock.uptimeMillis() -start);
23. }
24. //检查是否有线程或服务出问题了
25. finalint waitState =evaluateCheckerCompletionLocked();
26. if(waitState == COMPLETED) {
27. waitedHalf= false;
28. continue;
29. }else if (waitState == WAITING) {
30. continue;
31. }else if (waitState == WAITED_HALF) {
32. if(!waitedHalf) {
33. ArrayListpids = new ArrayList();
34. pids.add(Process.myPid());
35. ActivityManagerService.dumpStackTraces(true,pids, null, null,
36. NATIVE_STACKS_OF_INTEREST);
37. waitedHalf= true;
38. }
39. continue;
40. }
41. ......
42. {
43. //杀死SystemServer
44. Process.killProcess(Process.myPid());
45. System.exit(10);
46. }
47. waitedHalf= false;
48. }
49. }
代码清单10.2 WatchDog的线程执行函数run
run()方法中有一个无限循环，每次循环中主要做三件事：
1. 调用scheduleCheckLocked()方法给所有受监控的线程发送消息。scheduleCheckLocked()方法的代码如下
publicvoid scheduleCheckLocked() {
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()方法给被监控的线程发送一个消息。这个消息的处理方法是HandlerChecker类的方法run()，代码如下：
publicvoid run() {
final int 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()方法的实现通常如下：
publicvoid monitor() {
synchronized (mLock) {
}
}
2. 给受监控的线程发送完消息后，调用wait()方法让WatchDog线程睡眠一段时间。
3. 逐个检查是否有线程或服务出问题了，一旦发现问题，马上杀死进程。
前面的代码清单10.2第25行调用了方法evaluateCheckerCompletionLocked()来检查线程或服务是否有问题。evaluateCheckerCompletionLocked()方法的代码如下：
privateint evaluateCheckerCompletionLocked() {
int state = COMPLETED;
for (int i=0; i
HandlerChecker hc =mHandlerCheckers.get(i);
state = Math.max(state,hc.getCompletionStateLocked());
}
return state;
}
evaluateCheckerCompletionLocked()调用每个检查对象的getCompletionStateLocked()方法来得到对象的状态值。状态值有四种：
1) COMPLETED：值为0，表示状态良好。
2) WAITING：值为1，表示正在等待消息处理的结果。
3) WAITED_HALF：值为2，表示正在等待并且等待的时间超过了规定时间的一半了。
4) OVERDUE：值为3表示等待时间已经超过规定的时间。
evaluateCheckerCompletionLocked()方法希望知道的是最坏的情况，所以上面的代码中使用Math.max来计算出所有监控对象的最坏情况。
前面的代码清单10.2中的第26到40行在对返回的状态值做判断，只要不是OVERDUE状态都可以继续执行。否则就会杀死SystemServer进程。
其实这里使用三种状态就足够了：COMPLETED，WAITING和OVERDUE。WAITED_HALF这种状态是为了调试性能用的。如果某个线程或服务的执行时间超过了规定时间的一半，表明可能会出问题，系统就会把它的信息输出到Log中。这样开发人员通过查看Log就能看到潜在的问题，方便进行改善。参见代码清单10.2中的第35行。
getCompletionStateLocked()函数用来返回HandlerChecker对象的状态，代码如下：
public intgetCompletionStateLocked() {
if (mCompleted) {
return COMPLETED;
} else {
long latency = SystemClock.uptimeMillis() -mStartTime;
if (latency < mWaitMax/2) {
return WAITING;
} else if (latency < mWaitMax) {
return WAITED_HALF;
}
}
return OVERDUE;
}
getCompletionStateLocked()函数正是通过时间来判断被监控对象的状况。前面已经介绍的很清楚了，这里就不再分析了。