同步：ckitakishi.com

背景

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

原因

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

Watch Dog

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

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

同步網絡請求，主線程，超長超時時間，滿足這三點，一定場景下幾乎必然會觸發(fā)看門狗機制。

對策

合理解決方案：

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

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

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

應用的網絡部分基于公司的通用框架，因此優(yōu)先考慮在非主線程中進行網絡請求來避免觸發(fā)看門狗。

至于調試模式下為什么可以正常啟動應用，完全是因為該模式下看門狗機制處于禁用狀態(tài)。

此外，除了網絡操作，I/O 讀寫文件和大規(guī)模運算等耗時任務也極有可能觸發(fā)看門狗機制。合理處理線程，優(yōu)化耗時任務，很大程度能避免不佳用戶體驗。

參考：

1. 主線程上的同步網絡請求
2. 調試模式不發(fā)生崩潰