WatchDog源码分析

最新推荐文章于 2025-06-11 06:51:34 发布

置顶 junjle

最新推荐文章于 2025-06-11 06:51:34 发布

阅读量1k

点赞数

CC 4.0 BY-SA版权

分类专栏： android 文章标签： watchdog

本文链接：https://blog.youkuaiyun.com/junjle/article/details/83894362

android 专栏收录该内容

38 篇文章

订阅专栏

本文分析了WatchDog的源码，其基本原理是通过HandlerChecker在系统服务Loop队列前端post监测任务，若30s内未执行，视为卡顿，60s未完成则重启system_server。WatchDog主要检测死锁，例如ActivityManagerService和MediaProjectionManagerService的monitor()方法。然而，postAtFrontOfQueue可能导致WatchDog的run方法无法执行，引发误判和性能影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

看了一下watchdog的源码总结一下

基本原理

HandlerChecker 是基本的检测类，scheduleCheckLocked里面会记录开始时间并将minitor()检测方法postAtFrontOfQueue到Loop的队列前端，如果30s内没有执行到这个方法说明系统已经卡顿了（正常Loop队列前端的方法应该很快执行），

打印一次ActivityManagerService.dumpStackTraces。如果60s没有执行完 重启 并打印 堆栈信息，重启的目的是重新初始化system_server避免一直卡下去

其中monitor方法作为执行的检测办法被各个检测对象实现，大都是一些获取锁的操作，用来检测死锁情况

下面是几个类重写的monitor()方法
1. ActivityManagerService 只调用了synchronized 用来检测死锁没有其他动作
  1. ```
  /** In this method we try to acquire our lock to make sure that we have not deadlocked */
  public void monitor() {
  synchronized (this) { }
  }
```
2. MediaProjectionManagerService 也是检测死锁
  1. @Override
    publicvoidmonitor() {
    synchronized (mLock) {
    /* check for deadlock */ }
    }

watchdog原理非常简单，就是开启一个叫做watchdog的线程，然后不停的往要检测线程的Loop队列头部发送任务，如果1分钟之内执行完说明当前检测的线程不卡，否则发生了卡顿，打印log，重启system_server
有几个问题
1. 其他地方可能也会postAtFrontOfQueue 导致watchdog的run方法没有机会执行，1分钟之后也会触发超时
2. monitor方法本身也会耗时一方面会有误判断情况，另一方面也会对系统响应速度差生影响
参考网址：http://gityuan.com/2016/06/21/watchdog/

具体打印的trace信息有时间再研究一下格式