iOS-watchdog看門狗機制

背景

應用 100% Loss 時完全無法啟動，一直崩潰。徹底切斷網路連接正常啟動，偵錯模式狀態下等待時間非常久，但可以啟動，並伴隨 UI 微卡。強烈的預感這是線程阻塞。前一段時間被 Core Data Concurrency 折騰的夠嗆，看見線程問題就略有些心慌。 原因

首先看了 crash log，一如猜測，的確是卡在了主線程；意料之外的是，無數次閃退只留下了一份崩潰日誌，如下所示：

第一次見，讀了一些資料大概才算是明白了這是怎麼一回事。為了避免應用陷入錯誤狀態導致介面無響應，Apple 設計了看門狗 (WatchDog) 機制。一旦逾時，強制殺死進程。在不同的生命週期，觸發看門狗機制的逾時時間有所不同：

首先說一說異常編碼，也是寓意頗深。8badf00d = ate bad food，大概是在說看門狗吃了壞的食物所以暴走了。。異常記錄則表示這並不是一次崩潰（邪魅一笑：強制退出而已）。資訊一欄指出時間限制為 20 s。結合應用業務來看，表層原因在於：每次啟動應用，首先進行一次模版同步，在此之前需要檢測登入狀況，通過 RunLoop 反覆嘗試直到收到響應為止。然而不幸的是，這一些都發生在主線程。

同步網路請求，主線程，超長逾時時間，滿足這三點，一定情境下幾乎必然會觸發看門狗機制。 對策

合理解決方案： 非同步網路請求：優點很多，最重要的是可以讓你無憂無慮安全地訪問網路，而無需擔心線程。 在非主線程中使用同步網路請求：如果非同步運行你的網路代碼比登天還難的話(也許你的應用是一個基於同步網路請求的大型移植項目)，退而求次，你也可以在次級線程中運行同步代碼，也可以避免觸發看門狗機制。

此外，一部分情況下，例如這次遇到登入和模版同步時觸發看門狗，事實上，即使在運用到模版時再次請求也是勉強可行的，因此姑且先跳過網路請求也可以。此時，還以使用一種我認為是相對比較差的方案： 通過 RunLoop 來操控一切，一旦超過既定的逾時時間，就提示使用者重試或者暫時先跳過網路請求。

應用的網路部分基於公司的通用架構，因此優先考慮在非主線程中進行網路請求來避免觸發看門狗。

至於偵錯模式下為什麼可以正常啟動應用，完全是因為該模式下看門狗機制處于禁用狀態。

此外，除了網路操作，I/O 讀寫檔案和大規模運算等耗時任務也極有可能觸發看門狗機制。合理處理線程，最佳化耗時任務，很大程度能避免不佳使用者體驗。 參考： 主線程上的同步網路請求 偵錯模式不發生崩潰 連結：https://www.jianshu.com/p/2e47ad0c8fce