為保障線上 App 的用戶體驗焕参，我們一般都會對線上 App 的 crash 率做實時監(jiān)控轻纪，一旦檢測到 spike，可以即刻調查原因叠纷，但這一切的前提是 crash 日志能夠準確上報刻帚。
crash 日志上報有兩個難點：
-
crash handler 安裝之前的代碼要絕對穩(wěn)定
如果日志采集器還沒成功啟動就 crash 了，自然什么日志也無法采集到涩嚣。這一點并沒有太多技巧可言崇众，只能嚴格限制 handler 啟動之前可以執(zhí)行的代碼掂僵。
-
App 無限循環(huán) crash 時上報
crash 日志上報時，會發(fā)送網(wǎng)絡請求顷歌，如果請求成功之前 App 又發(fā)生 crash 該如何處理锰蓬？用戶甚至會陷入無限循環(huán)的 crash 中。
這篇文章介紹下出現(xiàn)第二種情況時眯漩，如何準確上報 crash 日志芹扭。
首先我們需要一種比較可靠的方式，可以在 app 啟動時判斷上次是否發(fā)生了啟動 crash坤塞。介紹一個可行的思路冯勉。
如何檢測連續(xù)閃退
連續(xù)閃退包含兩個元素，閃退和連續(xù)摹芙。只有這兩個元素同時具備時灼狰，才會影響我們的日志上傳。閃退的定義可以簡單為
app crash 時間 - app 啟動時間 <= 5s (或者其他 threshold)
連續(xù)的定義為浮禾，至少接連出現(xiàn)兩次或者以上交胚。一般 2 次就夠了，很多時候用戶連續(xù)經(jīng)歷兩次閃退盈电，就會放棄嘗試蝴簇。
我們可以通過記錄若干個特殊的時間點 timestamp 來試圖還原 App crash 場景下的生命周期。
-
App 啟動 timestamp匆帚，定義為 launchTs
App 每次啟動時熬词，記錄當前時間，寫入時間數(shù)組吸重。
-
App crash timestamp互拾，定義為 crashTs
App 每次啟動時，通過 crash 采集庫嚎幸，獲取上次 crash report 的時間戳颜矿，寫入時間數(shù)組。
-
App 正常退出 timestamp嫉晶，定義為 terminateTs
App 在接收到 UIApplicationWillTerminateNotification 通知時骑疆，記錄當前時間戳，寫入時間數(shù)組替废。注意箍铭，還有很多種 App 退出行為的時間戳是無法被準確記錄的。
之所以要記錄 terminateTs椎镣，是為了排除一種特殊情況坡疼，即用戶啟動 App 之后立即手動 kill app。如果我們正確記錄了上面三個時間戳衣陶，那么我們可以得到一個與 App crash 行為相關的時間線柄瑰。比如：
launchTs => crashTs => launchTs => terminateTs
或者
launchTs => launchTs => launchTs
或者
launchTs => crashTs => launchTs => crashTs => launchTs
請自行腦洞上面三種時間線的行為特征。很明顯剪况，第三種時間線看上去是連續(xù) crash 了兩次教沾。我們只需要加上時間間隔判斷，就能得知是否為連續(xù)兩次閃退了译断。注意授翻，如果兩個 crashTs 之間如果存在 terminateTs，則不能被認為是連續(xù)閃退孙咪。檢測代碼比較簡單堪唐，我就不貼了。
這個時間線只是記錄與 crash 相關的 App 啟動和退出行為翎蹈，還有很多特殊的時間點沒有記錄淮菠，比如 App 在 前臺發(fā)生 out of memory（FOOM），App 在前臺 main thread 卡住被系統(tǒng) Watch Dog 殺掉荤堪，iOS 系統(tǒng)升級時 App 被強殺合陵，App 從 AppStore 升級時被強殺等等，這些特殊的時間點都沒有記錄澄阳，不過這些并不影響我們的 App 連續(xù)閃退檢測拥知，所以可以忽略。
這里指的注意的是碎赢，因為啟動時要從 disk 讀取時間線記錄低剔，涉及磁盤讀寫，會對 App 的啟動時間產(chǎn)生影響肮塞，一個優(yōu)化點是襟齿，在每次寫入時間點移除掉較老的 timestamp，比如只記錄最近 5 個時間戳峦嗤∪锾疲或者在沒有讀取到 crash 日志時，甚至不用啟動連續(xù)閃退檢測的整個流程烁设。
接下來替梨，我們看假設檢測到連續(xù)閃退，我們?nèi)绾卫^續(xù)上傳日志装黑。
同步等待 Crash 日志上傳
最直白的方式副瀑，在 App 的代碼繼續(xù)執(zhí)行之前，先等待日志上傳成功恋谭。
把網(wǎng)絡請求改成同步的糠睡？這會卡住 UI 線程，網(wǎng)絡差的場景下會被系統(tǒng) watch dog 強殺疚颊，顯然不可取狈孔。
我們可以依舊保持異步網(wǎng)絡請求信认，但是，暫時中斷 UI 線程的流程均抽，讓整個 App 處于 UI 線程的 runloop 等待中嫁赏，一旦網(wǎng)絡請求成功，則跳回到 UI 線程的原有代碼流程油挥。
看著簡單的實現(xiàn)潦蝇，有幾個細節(jié)需要注意。首先我們需要增加一個 App 交互深寥，一旦進入 runloop 等待攘乒，展示一個 loading 界面，告知用戶耐心等待惋鹅。其次则酝，這個等待時間不能過長，我個人建議不超過 5s负饲，一旦超過 5s堤魁，無論 crash 日志上傳的 request 是否成功，都恢復 App 原有代碼流程返十。5s 內(nèi)日志都無法上傳成功的情況應該比較小妥泉，除非日志文件過大。
這種做法缺陷也很明顯洞坑，一是改動比較大（修改了原有代碼流程）盲链，二是需要增加新的 UI 交互，三是延長了用戶的等待時間迟杂。
我們來看另一種取巧的做法刽沾。
啟用后臺進程上傳 Crash 日志
其實最理想的日志上傳，是將上傳的 request 放到另一個不同的進程排拷，那么即使 App 又發(fā)生閃退侧漓，也不會影響到另一個進程代碼的執(zhí)行。
問題是监氢，iOS app 都處于 sandbox 環(huán)境下布蔗，系統(tǒng)不允許代碼 fork 一個新進程。
幸運的是浪腐，從 iOS 8 開始纵揍，系統(tǒng)對 NSURLSession 新增了一個 background session 特性。這個特性允許 NSURLSession 將網(wǎng)絡請求放入到一個單獨的進程中執(zhí)行议街。我個人感覺泽谨，這個特性設計，原本是為了增強某些 App 后臺下載音視頻等資源的體驗。我實際測試下來吧雹，發(fā)現(xiàn)不管下載或者是上傳骨杂，我們都可以將網(wǎng)絡請求放入另一個進程。代碼也很簡單雄卷，比如我寫一段如下的測試代碼：
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 進程如何替我們完成網(wǎng)絡請求，并試圖喚醒已經(jīng)異常退出的 App龙亲。
當然這種最理想的方式，也有一些細節(jié)需要處理悍抑。比如如何告知 App 某個 crash 日志上傳成功鳄炉，并從本地移除。由于連續(xù)閃退的 App 處于極度不穩(wěn)定的狀態(tài)搜骡，所以任何代碼邏輯都無法確保順利完成拂盯。
我個人感覺一種比較理想的方式是，給后臺進程上報的日志加上某個特殊的 flag记靡，然后在后臺通過 client request ID 和這個 flag 來做去重和整理谈竿。
線上 App 連續(xù)閃退是一種極其惡劣和可怕的故障，可怕之處在于摸吠，發(fā)生大面積連續(xù)閃退且無法被監(jiān)控時空凸，你正哼著小曲敲著代碼，老板突然發(fā)現(xiàn)自己手機上 App 啟動不了了寸痢，一打開 AppStore呀洲，發(fā)現(xiàn)一星差評潮水般涌來，如果是主流 App 甚至還會上科技新聞啼止，不難預料一口黑漆漆的大鍋正在成形道逗。下次 App 的升級介紹里一定會出現(xiàn) "fire peter" 了。
全文完献烦。
