為保障線上 App 的用戶體驗(yàn)，我們一般都會(huì)對(duì)線上 App 的 crash 率做實(shí)時(shí)監(jiān)控，一旦檢測(cè)到 spike，可以即刻調(diào)查原因，但這一切的前提是 crash 日志能夠準(zhǔn)確上報(bào)。

[[225352]]

crash 日志上報(bào)有兩個(gè)難點(diǎn)：

crash handler 安裝之前的代碼要絕對(duì)穩(wěn)定

• 如果日志采集器還沒成功啟動(dòng)就 crash 了，自然什么日志也無(wú)法采集到。這一點(diǎn)并沒有太多技巧可言，只能嚴(yán)格限制 handler 啟動(dòng)之前可以執(zhí)行的代碼。

App ***循環(huán) crash 時(shí)上報(bào)

• crash 日志上報(bào)時(shí)，會(huì)發(fā)送網(wǎng)絡(luò)請(qǐng)求，如果請(qǐng)求成功之前 App 又發(fā)生 crash 該如何處理?用戶甚至?xí)萑?**循環(huán)的 crash 中。

這篇文章介紹下出現(xiàn)第二種情況時(shí)，如何準(zhǔn)確上報(bào) crash 日志。

首先我們需要一種比較可靠的方式，可以在 app 啟動(dòng)時(shí)判斷上次是否發(fā)生了啟動(dòng) crash。介紹一個(gè)可行的思路。

如何檢測(cè)連續(xù)閃退

連續(xù)閃退包含兩個(gè)元素，閃退和連續(xù)。只有這兩個(gè)元素同時(shí)具備時(shí)，才會(huì)影響我們的日志上傳。閃退的定義可以簡(jiǎn)單為

app crash 時(shí)間 - app 啟動(dòng)時(shí)間 <= 5s (或者其他 threshold) 

連續(xù)的定義為，至少接連出現(xiàn)兩次或者以上。一般 2 次就夠了，很多時(shí)候用戶連續(xù)經(jīng)歷兩次閃退，就會(huì)放棄嘗試。

我們可以通過記錄若干個(gè)特殊的時(shí)間點(diǎn) timestamp 來試圖還原 App crash 場(chǎng)景下的生命周期。

App 啟動(dòng) timestamp，定義為 launchTs

• App 每次啟動(dòng)時(shí)，記錄當(dāng)前時(shí)間，寫入時(shí)間數(shù)組。

App crash timestamp，定義為 crashTs

• App 每次啟動(dòng)時(shí)，通過 crash 采集庫(kù)，獲取上次 crash report 的時(shí)間戳，寫入時(shí)間數(shù)組。

App 正常退出 timestamp，定義為 terminateTs

• App 在接收到 UIApplicationWillTerminateNotification 通知時(shí)，記錄當(dāng)前時(shí)間戳，寫入時(shí)間數(shù)組。注意，還有很多種 App 退出行為的時(shí)間戳是無(wú)法被準(zhǔn)確記錄的。

之所以要記錄 terminateTs，是為了排除一種特殊情況，即用戶啟動(dòng) App 之后立即手動(dòng) kill app。如果我們正確記錄了上面三個(gè)時(shí)間戳，那么我們可以得到一個(gè)與 App crash 行為相關(guān)的時(shí)間線。比如：

launchTs => crashTs => launchTs => terminateTs 

或者

launchTs => launchTs => launchTs 

或者

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

請(qǐng)自行腦洞上面三種時(shí)間線的行為特征。很明顯，第三種時(shí)間線看上去是連續(xù) crash 了兩次。我們只需要加上時(shí)間間隔判斷，就能得知是否為連續(xù)兩次閃退了。注意，如果兩個(gè) crashTs 之間如果存在 terminateTs，則不能被認(rèn)為是連續(xù)閃退。檢測(cè)代碼比較簡(jiǎn)單，我就不貼了。

這個(gè)時(shí)間線只是記錄與 crash 相關(guān)的 App 啟動(dòng)和退出行為，還有很多特殊的時(shí)間點(diǎn)沒有記錄，比如 App 在 前臺(tái)發(fā)生 out of memory(FOOM)，App 在前臺(tái) main thread 卡住被系統(tǒng) Watch Dog 殺掉，iOS 系統(tǒng)升級(jí)時(shí) App 被強(qiáng)殺，App 從 AppStore 升級(jí)時(shí)被強(qiáng)殺等等，這些特殊的時(shí)間點(diǎn)都沒有記錄，不過這些并不影響我們的 App 連續(xù)閃退檢測(cè)，所以可以忽略。

這里指的注意的是，因?yàn)閱?dòng)時(shí)要從 disk 讀取時(shí)間線記錄，涉及磁盤讀寫，會(huì)對(duì) App 的啟動(dòng)時(shí)間產(chǎn)生影響，一個(gè)優(yōu)化點(diǎn)是，在每次寫入時(shí)間點(diǎn)移除掉較老的 timestamp，比如只記錄最近 5 個(gè)時(shí)間戳?；蛘咴跊]有讀取到 crash 日志時(shí)，甚至不用啟動(dòng)連續(xù)閃退檢測(cè)的整個(gè)流程。

接下來，我們看假設(shè)檢測(cè)到連續(xù)閃退，我們?nèi)绾卫^續(xù)上傳日志。

同步等待 Crash 日志上傳

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

把網(wǎng)絡(luò)請(qǐng)求改成同步的?這會(huì)卡住 UI 線程，網(wǎng)絡(luò)差的場(chǎng)景下會(huì)被系統(tǒng) watch dog 強(qiáng)殺，顯然不可取。

我們可以依舊保持異步網(wǎng)絡(luò)請(qǐng)求，但是，暫時(shí)中斷 UI 線程的流程，讓整個(gè) App 處于 UI 線程的 runloop 等待中，一旦網(wǎng)絡(luò)請(qǐng)求成功，則跳回到 UI 線程的原有代碼流程。

看著簡(jiǎn)單的實(shí)現(xiàn)，有幾個(gè)細(xì)節(jié)需要注意。首先我們需要增加一個(gè) App 交互，一旦進(jìn)入 runloop 等待，展示一個(gè) loading 界面，告知用戶耐心等待。其次，這個(gè)等待時(shí)間不能過長(zhǎng)，我個(gè)人建議不超過 5s，一旦超過 5s，無(wú)論 crash 日志上傳的 request 是否成功，都恢復(fù) App 原有代碼流程。5s 內(nèi)日志都無(wú)法上傳成功的情況應(yīng)該比較小，除非日志文件過大。

這種做法缺陷也很明顯，一是改動(dòng)比較大(修改了原有代碼流程)，二是需要增加新的 UI 交互，三是延長(zhǎng)了用戶的等待時(shí)間。

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

啟用后臺(tái)進(jìn)程上傳 Crash 日志

其實(shí)最理想的日志上傳，是將上傳的 request 放到另一個(gè)不同的進(jìn)程，那么即使 App 又發(fā)生閃退，也不會(huì)影響到另一個(gè)進(jìn)程代碼的執(zhí)行。

問題是，iOS app 都處于 sandbox 環(huán)境下，系統(tǒng)不允許代碼 fork 一個(gè)新進(jìn)程。

幸運(yùn)的是，從 iOS 8 開始，系統(tǒng)對(duì) NSURLSession 新增了一個(gè) background session 特性。這個(gè)特性允許 NSURLSession 將網(wǎng)絡(luò)請(qǐng)求放入到一個(gè)單獨(dú)的進(jìn)程中執(zhí)行。我個(gè)人感覺，這個(gè)特性設(shè)計(jì)，原本是為了增強(qiáng)某些 App 后臺(tái)下載音視頻等資源的體驗(yàn)。我實(shí)際測(cè)試下來，發(fā)現(xiàn)不管下載或者是上傳，我們都可以將網(wǎng)絡(luò)請(qǐng)求放入另一個(gè)進(jìn)程。代碼也很簡(jiǎn)單，比如我寫一段如下的測(cè)試代碼：

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(0); 

執(zhí)行之后，我們可以在 console 中看到如下日志：

可以清楚的看到 nsurlsessiond 進(jìn)程如何替我們完成網(wǎng)絡(luò)請(qǐng)求，并試圖喚醒已經(jīng)異常退出的 App。

當(dāng)然這種最理想的方式，也有一些細(xì)節(jié)需要處理。比如如何告知 App 某個(gè) crash 日志上傳成功，并從本地移除。由于連續(xù)閃退的 App 處于極度不穩(wěn)定的狀態(tài)，所以任何代碼邏輯都無(wú)法確保順利完成。

我個(gè)人感覺一種比較理想的方式是，給后臺(tái)進(jìn)程上報(bào)的日志加上某個(gè)特殊的 flag，然后在后臺(tái)通過 client request ID 和這個(gè) flag 來做去重和整理。

線上 App 連續(xù)閃退是一種極其惡劣和可怕的故障，可怕之處在于，發(fā)生大面積連續(xù)閃退且無(wú)法被監(jiān)控時(shí)，你正哼著小曲敲著代碼，老板突然發(fā)現(xiàn)自己手機(jī)上 App 啟動(dòng)不了了，一打開 AppStore，發(fā)現(xiàn)一星差評(píng)潮水般涌來，如果是主流 App 甚至還會(huì)上科技新聞，不難預(yù)料一口黑漆漆的大鍋正在成形。下次 App 的升級(jí)介紹里一定會(huì)出現(xiàn) "fire peter" 了。

全文完。