iOS App 連續閃退時如何上報 crash 日志

為保障線上 App 的使用者體驗，我們一般都會對線上 App 的 crash 率做實時監控，一旦檢測到 spike，可以即刻調查原因，但這一切的前提是 crash 日志能夠準确上報。

crash 日志上報有兩個難點：

• crash handler 安裝之前的代碼要絕對穩定

  如果日志采集器還沒成功啟動就 crash 了，自然什麼日志也無法采集到。這一點并沒有太多技巧可言，隻能嚴格限制 handler 啟動之前可以執行的代碼。

• App 無限循環 crash 時上報

  crash 日志上報時，會發送網絡請求，如果請求成功之前 App 又發生 crash 該如何處理？使用者甚至會陷入無限循環的 crash 中。

這篇文章介紹下出現第二種情況時，如何準确上報 crash 日志。

首先我們需要一種比較可靠的方式，可以在 app 啟動時判斷上次是否發生了啟動 crash。介紹一個可行的思路。

如何檢測連續閃退

連續閃退包含兩個元素，閃退和連續。隻有這兩個元素同時具備時，才會影響我們的日志上傳。閃退的定義可以簡單為

1	app crash 時間 -  app 啟動時間 <= 5s (或者其他 threshold)

連續的定義為，至少接連出現兩次或者以上。一般 2 次就夠了，很多時候使用者連續經曆兩次閃退，就會放棄嘗試。

我們可以通過記錄若幹個特殊的時間點 timestamp 來試圖還原 App crash 場景下的生命周期。

• App 啟動 timestamp，定義為 launchTs

  App 每次啟動時，記錄目前時間，寫入時間數組。

• App crash timestamp，定義為 crashTs

  App 每次啟動時，通過 crash 采集庫，擷取上次 crash report 的時間戳，寫入時間數組。

• App 正常退出 timestamp，定義為 terminateTs

  App 在接收到 UIApplicationWillTerminateNotification 通知時，記錄目前時間戳，寫入時間數組。注意，還有很多種 App 退出行為的時間戳是無法被準确記錄的。

之是以要記錄 terminateTs，是為了排除一種特殊情況，即使用者啟動 App 之後立即手動 kill app。如果我們正确記錄了上面三個時間戳，那麼我們可以得到一個與 App crash 行為相關的時間線。比如：

1	launchTs => crashTs => launchTs => terminateTs

或者

1	launchTs => launchTs => launchTs

或者

1	launchTs => crashTs => launchTs => crashTs => launchTs

請自行腦洞上面三種時間線的行為特征。很明顯，第三種時間線看上去是連續 crash 了兩次。我們隻需要加上時間間隔判斷，就能得知是否為連續兩次閃退了。注意，如果兩個 crashTs 之間如果存在 terminateTs，則不能被認為是連續閃退。檢測代碼比較簡單，我就不貼了。

這個時間線隻是記錄與 crash 相關的 App 啟動和退出行為，還有很多特殊的時間點沒有記錄，比如 App 在 前台發生 out of memory（FOOM），App 在前台 main thread 卡住被系統 Watch Dog 殺掉，iOS 系統更新時 App 被強殺，App 從 AppStore 更新時被強殺等等，這些特殊的時間點都沒有記錄，不過這些并不影響我們的 App 連續閃退檢測，是以可以忽略。

這裡指的注意的是，因為啟動時要從 disk 讀取時間線記錄，涉及磁盤讀寫，會對 App 的啟動時間産生影響，一個優化點是，在每次寫入時間點移除掉較老的 timestamp，比如隻記錄最近 5 個時間戳。或者在沒有讀取到 crash 日志時，甚至不用啟動連續閃退檢測的整個流程。

接下來，我們看假設檢測到連續閃退，我們如何繼續上傳日志。

同步等待 Crash 日志上傳

最直白的方式，在 App 的代碼繼續執行之前，先等待日志上傳成功。

把網絡請求改成同步的？這會卡住 UI 線程，網絡差的場景下會被系統 watch dog 強殺，顯然不可取。

我們可以依舊保持異步網絡請求，但是，暫時中斷 UI 線程的流程，讓整個 App 處于 UI 線程的 runloop 等待中，一旦網絡請求成功，則跳回到 UI 線程的原有代碼流程。

看着簡單的實作，有幾個細節需要注意。首先我們需要增加一個 App 互動，一旦進入 runloop 等待，展示一個 loading 界面，告知使用者耐心等待。其次，這個等待時間不能過長，我個人建議不超過 5s，一旦超過 5s，無論 crash 日志上傳的 request 是否成功，都恢複 App 原有代碼流程。5s 内日志都無法上傳成功的情況應該比較小，除非日志檔案過大。

這種做法缺陷也很明顯，一是改動比較大（修改了原有代碼流程），二是需要增加新的 UI 互動，三是延長了使用者的等待時間。

我們來看另一種取巧的做法。

啟用背景程序上傳 Crash 日志

其實最理想的日志上傳，是将上傳的 request 放到另一個不同的程序，那麼即使 App 又發生閃退，也不會影響到另一個程序代碼的執行。

問題是，iOS app 都處于 sandbox 環境下，系統不允許代碼 fork 一個新程序。

幸運的是，從 iOS 8 開始，系統對 NSURLSession 新增了一個 background session 特性。這個特性允許 NSURLSession 将網絡請求放入到一個單獨的程序中執行。我個人感覺，這個特性設計，原本是為了增強某些 App 背景下載下傳音視訊等資源的體驗。我實際測試下來，發現不管下載下傳或者是上傳，我們都可以将網絡請求放入另一個程序。代碼也很簡單，比如我寫一段如下的測試代碼：

1 2 3 4 5 6 7

NSURLSessionConfiguration *config = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier:@ "com.mrpeak.background.crashupload" ]; NSURLSession *session = [NSURLSession sessionWithConfiguration:config delegate:self delegateQueue:[NSOperationQueue  new ]]; NSURL *url = [NSURL URLWithString:@ "https://images.unsplash.com/photo-1515816949419-7caf0a210607?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=f46b60857b4826e733da34993ec26a2f&auto=format&fit=crop&w=1534&q=80" ]; NSURLSessionDownloadTask *task = [session downloadTaskWithURL:url]; [task resume]; exit( );

執行之後，我們可以在 console 中看到如下日志：

ioscrashupload00.png

可以清楚的看到 nsurlsessiond 程序如何替我們完成網絡請求，并試圖喚醒已經異常退出的 App。

當然這種最理想的方式，也有一些細節需要處理。比如如何告知 App 某個 crash 日志上傳成功，并從本地移除。由于連續閃退的 App 處于極度不穩定的狀态，是以任何代碼邏輯都無法確定順利完成。

我個人感覺一種比較理想的方式是，給背景程序上報的日志加上某個特殊的 flag，然後在背景通過 client request ID 和這個 flag 來做去重和整理。

線上 App 連續閃退是一種極其惡劣和可怕的故障，可怕之處在于，發生大面積連續閃退且無法被監控時，你正哼着小曲敲着代碼，老闆突然發現自己手機上 App 啟動不了了，一打開 AppStore，發現一星差評潮水般湧來，如果是主流 App 甚至還會上科技新聞，不難預料一口黑漆漆的大鍋正在成形。下次 App 的更新介紹裡一定會出現 "fire peter" 了。