Android架构纵横谈之——软件自愈能力 （3）

本系列2012年的时候发表在我的blog上面，现搬到公众号

接上回：

Android架构纵横谈之——软件自愈能力 （1）

Android架构纵横谈之——软件自愈能力 （2）

上回书(Android架构纵横谈之——软件自愈能力 （2）)说到Android中生死与共的Zygote和SystemServer，今回书我们讲SystemServer的watchdog，也为软件架构自愈系列的终结篇。

第三只狗：朝廷鹰犬

“走狗”、“鹰犬”的特点是，对主人卑躬屈膝，对民间进行秘密监控、暴力镇压、实施酷刑等，搞到人人自危。在Android的世界里，这样的“走狗”也必然存在。在SystemServer启动一些service后，它需要不断监视一些重要service的状况，一旦发现某个service有异动，思想上与统治者长期不一致，势必要采取行动。在SystemService的众多service中，重点监控对象包括ActivityManagerService 、PowerManagerService、WindowManagerService等，这个监控透过Android的watchdog实现 。

在一个典型的嵌入式系统中，会存在一个硬件看门狗，正常运转的系统会周期喂狗，否则证明系统hang了。硬件看门狗存在相当大的局限性，它只能监控整个系统而不能监控单个的进程或者线程。于是发明软件看门狗意义重大。SystemServer会用到软件看门狗来确保AM 、PM、WM这几个服务hang住之后，退出SystemServer进程，从而进入上回书中的Zygote与SystemServer的生死与共。注意service是hang而不是死，绕到个死胡同里出不来了。镜湖女侠决定了革命，你再怎么去说服她也没有用了。

我们随便读一下PowerManagerService.java的源代码，会发现几乎所有的重要操作都会透过synchronized其中的mLocks进行，咱们抓几个看看：

很显然，如果我们故意去synchronizedmLocks这个锁，如果长时间拿不到，基本可认定PowerManagerService在某个操作里面hang了，短时间或者直接就拿到了，证明一切正常。PowerManagerService里面实现了monitor成员函数来synchronized mLocks：

同样的道理，对于其他的几个service，我们也可以用类似的方法来验证它们是否hang。同志们啊，很多国内的书或者文档里面把这个侦测hang的过程说成是侦测死锁，含义其实是大错特错了，也把广大的读者搞地不知所云。因为死锁只是引起hang的一种可能，hang的含义则更加广泛。缓刑或者监外执行的罪犯，周期性地会去派出所报告工作，如果没去报告，很可能不是被家里人死锁在房间里打不开门了，更可能是跑路了。

了解了侦测service hang的原理，我们需要一套方法来实现这个侦测，这个过程透过watchdog来实现。在Android中，watchdog继承于thread类，代码位于frameworks/base/services/java/com/android/server/Watchdog.java。采用单例模式，提供getInstance() 接口，同时在watchdog创建的过程中，会创建一个用于消息处理的HeartbeatHandler：

SystemServer会调用watchdog的start函数，从而让继承于thread的Watchdog的run函数在一新线程被执行：

这个run函数实现比较简单， 周期性地设置mCompleted变量为假，通知心跳handler去调用各个monitor，而心跳handler会调用各个service的monitor，如果各个monitor都返回了，心跳handler会将mCompleted设置为真(这个过程是不是和使用硬件看门狗的情况下把定时器复位惊人的相似？因此，我们可以把这个过程看做“喂狗”)。否则，经过2次等待watchgod的run()发现mCompleted还为假，就证明hang了。我们看看心跳handler调用各个monitor的过程并“喂狗”的过程：

而PowerManagerService等service如何进入上面代码中的for循环呢？那是因为他们正好实现了这个Watchdog.Monitor接口，并透过Watchdog.getInstance().addMonitor(this)加到了monitor列表里面。

结合第一回和第二回，我们基本可以看出整个Android软件自愈过程的“环环相扣”，成为一个多么完美的体系啊！SystemServer监控重要service，重要service hang则SystemServer死，SystemServer死则Zygote监控到，Zygote也死并且杀死整个Java世界，Zygote死则init监控到，init重新启动Zygote，之后SystemServer、service又进入重生过程，与死亡的过程相反。

这个过程我们看到了多进程之间的千丝万缕的联系，以及多进程模型的魅力和设计哲学，程序员喜欢孤立的去看待自己的程序而不是总揽全局，而从体系架构的角度去思考问题，我们更加能清楚我们位于整个软件的哪个组成部分。和宇宙大爆炸比起来，咱屌丝们的房子、车子都不过是过眼云烟，所以我们要尽快把自己的人生理想调整到配合宇宙大爆炸的方向上来。从Android的init、Zygote、SystemServer和重要service的彼此关联中，我们至少体会到了一些什么，整天盯着自己的几个函数玩，不在宇宙里玩，玩地多不过瘾啊？关系上是“宇宙大爆炸－>Android-> 程序员”，不是“函数->模块->Android”，这是研究Android的方法学。谁可以帮我p一副图？把下面这个宇宙大爆炸图中p出个Android，旁边再p出个苦B程序员呢？

在朝廷鹰犬的监控之下，无法与朝廷保持一致的service革命者就这样被watchdog给揪了出来。鹰犬问道，你只要放弃你的信念，保持喂狗，就可以活。而他（她）毅然选择了慷慨负死。威廉·华莱士道：“跟着我，你们将失去生命，但是，你们将获得自由” 。

汝体吾此心，

于啼泣之余，

亦以天下人为念，

当亦乐牺牲吾身与汝身之福利，

为天下人谋永福也。

汝其勿悲！