iOS 的看門狗機制

背景

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

原因

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

Watch Dog

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

生命週期	超時時間
啟動 Launch	20 s
恢復 Resume	10 s
懸掛 Suspend	10 s
退出 Quit	6 s
後臺 Background	10 min

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

同步網路請求，主執行緒，超長超時時間，滿足這三點，一定場景下幾乎必然會觸發看門狗機制。

對策

合理解決方案：

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

此外，一部分情況下，例如這次遇到登入和模版同步時觸發看門狗，事實上，即使在運用到模版時再次請求也是勉強可行的，因此姑且先跳過網路請求也可以。此時，還以使用一種我認為是相對比較差的方案：

1. 通過 RunLoop 來操控一切，一旦超過既定的超時時間，就提示使用者重試或者暫時先跳過網路請求。

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

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

此外，除了網路操作，I/O 讀寫檔案和大規模運算等耗時任務也極有可能觸發看門狗機制。合理處理執行緒，優化耗時任務，很大程度能避免不佳使用者體驗。

參考：

1. 主執行緒上的同步網路請求
2. 除錯模式不發生崩潰

作者：晨行北岸
連結：https://www.jianshu.com/p/2e47ad0c8fce
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。