1. HandlerChecker 是基本的檢測類，scheduleCheckLocked裡面會記錄開始時間並將minitor()檢測方法postAtFrontOfQueue到Loop的佇列前端，如果30s內沒有執行到這個方法說明系統已經卡頓了（正常Loop佇列前端的方法應該很快執行），

   列印一次ActivityManagerService.dumpStackTraces。如果60s沒有執行完 重啟 並列印 堆疊資訊，重啟的目的是重新初始化system_server避免一直卡下去

2. 其中monitor方法作為執行的檢測辦法被各個檢測物件實現，大都是一些獲取鎖的操作，用來檢測死鎖情況
3. 下面是幾個類重寫的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
         public

         voidmonitor() {
         synchronized (mLock) {
         /* check for deadlock */ }
         } 

watchdog原理非常簡單，就是 開啟一個叫做watchdog的執行緒，然後不停的往要檢測執行緒的Loop佇列頭部發送任務，如果1分鐘之內執行完說明當前檢測的執行緒不卡，否則發生了卡頓，列印log，重啟system_server

有幾個問題

1. 其他地方可能也會postAtFrontOfQueue 導致watchdog的run方法沒有機會執行，1分鐘之後也會觸發超時
2. monitor方法本身也會耗時一方面會有誤判斷情況，另一方面也會對系統響應速度差生影響