Android framework：watchdog

watchdog就是看門狗。以前實習公司的watchdog就是監視進程，如果進程掛了就重新啓動進程。

在Android中watchdog的原理也類似，通過向進程發送消息，判斷返回值延遲時間，若超時，通知zogte自殺，後面init會重啓zogte，所以重啓的是android，不影響kernel，速度較快。

盜個圖：

開始擼代碼：

---

1.啓動在systemserver：

final Watchdog watchdog = Watchdog.getInstance();

watchdog.init(context, mActivityManagerService);

Watchdog.getInstance().start();

---

2.getInstance是單例模式，就是調用watchdog的構造

    private Watchdog() {
        super("watchdog");
        // Initialize handler checkers for each common thread we want to check.  Note
        // that we are not currently checking the background thread, since it can
        // potentially hold longer running operations with no guarantees about the timeliness
        // of operations there.

        // The shared foreground thread is the main checker.  It is where we
        // will also dispatch monitor checks and do other work.
        mMonitorChecker = new HandlerChecker(FgThread.getHandler(),
                "foreground thread", DEFAULT_TIMEOUT);
        mHandlerCheckers.add(mMonitorChecker);
        // Add checker for main thread.  We only do a quick check since there
        // can be UI running on the thread.
        mHandlerCheckers.add(new HandlerChecker(new Handler(Looper.getMainLooper()),
                "main thread", DEFAULT_TIMEOUT));
        // Add checker for shared UI thread.
        mHandlerCheckers.add(new HandlerChecker(UiThread.getHandler(),
                "ui thread", DEFAULT_TIMEOUT));
        // And also check IO thread.
        mHandlerCheckers.add(new HandlerChecker(IoThread.getHandler(),
                "i/o thread", DEFAULT_TIMEOUT));
        // And the display thread.
        mHandlerCheckers.add(new HandlerChecker(DisplayThread.getHandler(),
                "display thread", DEFAULT_TIMEOUT));

        // Initialize monitor for Binder threads.
        addMonitor(new BinderThreadMonitor());

        mOpenFdMonitor = OpenFdMonitor.create();

        // See the notes on DEFAULT_TIMEOUT.
        assert DB ||
                DEFAULT_TIMEOUT > ZygoteConnectionConstants.WRAPPED_PID_TIMEOUT_MILLIS;
    }

在Watchdog構造函數中將main thread，UIthread，Iothread，DisplayThread加入mHandlerCheckers列表中。最後初始化monitor放入mMonitorCheckers列表中 ，還有binder和fd的monitor

---

3.watchdog監控

Watchdog提供兩種監視方式，一種是通過monitor()回調監視服務關鍵區是否出現死鎖或阻塞，一種是通過發送消息監視服務主線程是否阻塞。比如服務ams（monitor），跑在systemserver（發送消息）上。

addMonitor()

addThread()

monitor監控服務是通過服務實現watchdog的monitor接口，主動實現的。

發生watchdog時，會打印watchdog重啓時有有兩種提示語：“Block in Handler in ......”和“Block in monitor”，它們分別對應不同的阻塞類型

---

4.watchdog工作

watchdog是個thread，start就是調用run，看run函數，比較長

首先是進入無限循環，調用

scheduleCheckLocked();進行監控

進入這個函數裏面：

1.如果monitor空，或者線程正在發消息，直接返回true，此時不可能有阻塞

2.mComplete爲false，代表正在進行監控

3.若都不滿足，則postAtFrontOfQueue(this)，進行檢查

調用postAtFrontOfQueue後，如果沒有阻塞，則很快有返回，代表thread沒有阻塞，有返回就會調用它的run函數，調用相應服務的monitor，而monitor就是加個鎖，看能不能獲取到，獲取到就沒有阻塞

 @Override
        public void 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;
            }
        }

---

4.報異常邏輯

在每個監測過程中，調用evaluateCheckerCompletionLocked進行返回時間計算

complete就是沒有阻塞

waitting狀態就是時間在0~30，繼續等待

waited_half狀態實在30~59 時間過半，開始dump ams stacktrace

到60秒，就是有阻塞發生了

獲取阻塞的服務和線程，生成log和dropbox

最後開殺

Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + subject);
                WatchdogDiagnostics.diagnoseCheckers(blockedCheckers);
                Slog.w(TAG, "*** GOODBYE!");
                Process.killProcess(Process.myPid());
                System.exit(10);

---

5.接收廣播重啓

在init()函數中，接下來會調用registerReceiver()來註冊系統重啓的BroadcastReceiver。在收到系統重啓廣播時會執行RebootRequestReceiver的onReceive()函數，繼而調用rebootSystem()重啓系統。它允許其它模塊（如CTS）通過發廣播來讓系統重啓。所以watchdog有一個重要的工作，就是接收廣播並重啓系統。

---

盜了張圖：