iOSApp連續(xù)閃退時上報crash日志的方法詳解-創(chuàng)新互聯(lián)

前言

創(chuàng)新互聯(lián)公司主營寬城網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,App定制開發(fā),寬城h5微信平臺小程序開發(fā)搭建,寬城網(wǎng)站營銷推廣歡迎寬城等地區(qū)企業(yè)咨詢

當(dāng)一個iOS應(yīng)用程序崩潰時，系統(tǒng)會創(chuàng)建一份crash日志保存在設(shè)備上。這份crash日志記錄著應(yīng)用程序崩潰時的信息，通常包含著每個執(zhí)行線程的棧調(diào)用信息（低內(nèi)存閃退日志例外），對于開發(fā)人員定位問題很有幫助。

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

crash 日志上報有兩個難點：

crash handler 安裝之前的代碼要絕對穩(wěn)定
如果日志采集器還沒成功啟動就 crash 了，自然什么日志也無法采集到。這一點并沒有太多技巧可言，只能嚴(yán)格限制 handler 啟動之前可以執(zhí)行的代碼。
App 無限循環(huán) crash 時上報
crash 日志上報時，會發(fā)送網(wǎng)絡(luò)請求，如果請求成功之前 App 又發(fā)生 crash 該如何處理？用戶甚至?xí)萑霟o限循環(huán)的 crash 中。

這篇文章介紹下出現(xiàn)第二種情況時，如何準(zhǔ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 每次啟動時，記錄當(dāng)前時間，寫入時間數(shù)組。
App crash timestamp，定義為 crashTs
App 每次啟動時，通過 crash 采集庫，獲取上次 crash report 的時間戳，寫入時間數(shù)組。
App 正常退出 timestamp，定義為 terminateTs
App 在接收到 UIApplicationWillTerminateNotification 通知時，記錄當(dāng)前時間戳，寫入時間數(shù)組。注意，還有很多種 App 退出行為的時間戳是無法被準(zhǔn)確記錄的。

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

launchTs => crashTs => launchTs => terminateTs

或者

launchTs => launchTs => launchTs

或者

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

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

這個時間線只是記錄與 crash 相關(guān)的 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ù)閃退檢測的整個流程。

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

同步等待 Crash 日志上傳

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

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

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

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

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

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

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

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

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

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

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)建站muchs.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

文章名稱：iOSApp連續(xù)閃退時上報crash日志的方法詳解-創(chuàng)新互聯(lián)
網(wǎng)頁路徑：http://muchs.cn/article32/cddopc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、面包屑導(dǎo)航、網(wǎng)站制作、搜索引擎優(yōu)化、網(wǎng)站內(nèi)鏈、響應(yīng)式網(wǎng)站

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容