一、背景
崩潰(Crash),即閃退,多指移動設備(如iOS、Android設備)在打開/使用應用程序的過程中,突然出現意外退出/中斷的情況。如果App線上版本頻繁發生崩潰,會極大地影響用戶體驗,甚至導致用戶流失,以及收益減少。因此,崩潰問題是客戶端穩定性團隊需要重點解決的問題。
然而,對於所有崩潰場景,僅25%的崩潰可通過信號量捕獲,實施相應改進;另有75%的崩潰則難以識別,從而對App的用戶體驗,造成了巨大的潛在影響。
Facebook的工程師將App退出分爲以下6個類別:
1.App內部主動調用exit()或abort()退出;
2.App升級過程中,用戶進程被殺死;
3.系統升級過程中,用戶進程被殺死;
4.App在後臺被殺死;
5.App在前臺被殺死,且可獲取堆棧;
6.App在前臺被殺死,且無法獲取堆棧。
對於第1~4類退出,屬於App的正常退出,對用戶體驗沒有太大影響,無需進行相應處理;對於第5類退出,可通過堆棧代碼級定位崩潰原因,對此業界已形成比較成熟的解決方案,推薦免費試用阿里雲的崩潰分析服務,即可快速定位、解決此類崩潰問題;對於第6類退出,可能的原因很多,包括但不限於:系統內存不足時繼續申請內存、主線程卡死20s以上、CPU使用率過高Stack Overflow等,在此我們統一稱之爲iOS客戶端的“Abort問題”。
Abort問題無法被堆棧捕獲,且發生頻次遠高於可被捕獲的崩潰(下稱“堆棧崩潰”)。從歷史數據來看,手淘(電商類超級App代表)的Abort問題數量一般是堆棧崩潰數量的3倍左右;優酷Pad(視頻類超級App代表)的Abort問題數量一般是堆棧崩潰數量的5倍左右。可見,Abort問題對用戶的使用體驗造成巨大影響。
本文將針對iOS客戶端的Abort問題,進行根因定位分析,並提出系統性解決方案。
二、Abort問題的原因分類
形成Abort問題的原因主要包括以下4個。
2.1 內存Jetsam
移動端設備的物理內存資源緊張,但App仍不斷申請內存。因此係統signal 9殺死進程,造成異常退出。
{
"memoryPages" : {
"active" : 24493,
"throttled" : 0,
"fileBacked" : 24113,
"wired" : 13007,
"anonymous" : 12915,
"purgeable" : 127,
"inactive" : 10955,
"free" : 2290,
"speculative" : 1580
},
"uncompressed" : 125795,
"decompressions" : 143684
},
"largestProcess" : "Taobao4iPhone",
"processes" : [
{
...
{
"rpages" : 2050,
"states" : [
"frontmost",
"resume"
],
"name" : "Taobao4iPhone",
"pid" : 1518,
"reason" : "vm-thrashing",
"fds" : 50,
"uuid" : "5103a88a-917f-319e-8553-c0189dd1abac",
"purgeable" : 127,
"cpuTime" : 4.619693,
"lifetimeMax" : 3557
},
}
2.2 主線程死鎖
A/B兩個線程同時等待對方完成某些操作,因而無法繼續執行,形成死鎖,造成異常退出。
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread: 0
Application Specific Information:
com.myapp.myapp failed to scene-create in time
Elapsed total CPU time (seconds): 4.230 (user 4.230, system 0.000), 10% CPU
Elapsed application CPU time (seconds): 1.039, 3% CPU
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x36360540 semaphore_wait_trap + 8
1 libdispatch.dylib 0x36297eee _dispatch_semaphore_wait_slow + 186
2 libxpc.dylib 0x364077b8 xpc_connection_send_message_with_reply_sync + 152
3 Security 0x2b8dd310 securityd_message_with_reply_sync + 64
4 Security 0x2b8dd48c securityd_send_sync_and_do + 44
5 Security 0x2b8ea452 __SecItemCopyMatching_block_invoke + 166
6 Security 0x2b8e96f6 SecOSStatusWith + 14
7 Security 0x2b8ea36e SecItemCopyMatching + 174
2.3 啓動/重啓超時
App由於啓動/重啓的時間超過系統允許的時間限制,造成異常退出。
scene-create watchdog transgression: app exhausted real (wall clock) time allowance of 19.93 seconds, Elapsed total CPU time (seconds): 21.050 (user 21.050, system 0.000)
2.4 CPU打爆
主線程死鎖、啓動/重啓超時,都可能間接導致CPU打爆,造成異常退出。
三、Abort問題的根因定位
Abort問題常常沒有明顯線索進行問題定位,因此,解決難度比較大。手淘曾經歷過很多次Abort問題數量飆升,但無從下手的事故,甚至還有一兩次發生在雙11前不久,但往往以“一羣人苦逼的衆測復現、復現之後也無法確定是否真的復現”收場。
因此,我們迫切需要基於已有經驗,形成一套完整的解決方案,快速、準確地定位/解決問題。這就需要我們從以下幾個方面着手進行考慮:
1.Abort問題發生的場景:例如,哪個頁面、什麼操作。
2.Abort問題發生的原因:例如,內存Jetsam、主線程死鎖、啓動/重啓超時、CPU打爆。
3.對於內存Jetsam,需進一步定位到是否發生了內存泄露以及泄露的循環引用(Retain Cycle)。
4.對於主線程死鎖,需進一步定位到卡死的堆棧。
5.對於啓動/重啓超時,以及CPU打爆,需進一步定位到堆棧。
接下來,我們以手淘的主線程死鎖問題爲例,進行根因分析。首先,來看一下某版本手淘Abort問題數據的總體視圖:
由於Abort問題出現之前,內存、CPU使用量正常,因此初步判斷造成異常退出的原因爲主線程死鎖。
查看相關日誌文件,驗證時間、線索吻合,因此可最終確定造成異常退出的原因爲主線程死鎖。
四、Abort問題的系統性解決方案
4.1 Abort系統性解決方案難點:現場捕獲
爲實現Abort問題的系統性解決方案,需充分考慮以下問題:
1.通過signal 9殺死進程造成的Abort問題,往往難以通過信號量捕獲至堆棧。在這種情況下,應如何儘可能完整地捕獲崩潰現場的關鍵信息?具體包含哪些信息?
2.App崩潰時系統處於極不穩定的狀態,應如何保證崩潰現數據穩定落盤?
3.在信息採集、數據捕獲的過程中,需對大量數據進行寫入操作,應如何保證日誌高性能寫入?
4.在數據量較大的情況下,數據的存儲、上傳可能對系統造成較大壓力,應如何保證數據的高壓縮率?
基於以上考慮,我們提出並設計了一套基於mmap的高性能、高壓縮率、高一致性、可自解釋的trace文件協議,作爲iOS端高可用體系的數據載體。
4.1.1 mmap數據存儲層保證數據寫入的高性能和高一致性
1.通過mmap將一個文件或者其它對象映射到進程的地址空間,對內存的操作會由內核將數據寫到對應的磁盤文件上;數據寫入的性能與內存操作相當(略比內存操作高)
2.用戶進程崩潰之後,這塊映射區仍由內核管理,可以保證數據的一致性
4.1.2 二進制編碼協議保證數據壓縮率最高
1.具體編碼協議
2.實測編碼在壓縮率能達到80%以上,或者直觀一點說,使用50k的內存可以記錄下用戶二十分鐘內詳細的使用記錄,包括頁面訪問記錄、系統事件、秒級別的內存、CPU數據。
4.1.3 儘可能多的記錄系統多維度指標及異常事件
包括:
1.性能數據,包括CPU、內存數據,用於判斷應用當前是不是處理overload狀態
2.大內存申請
3.Retain Cycle,用於定位Jetsam Event
4.卡頓,用於定位watch dog kill
5.當前存活VC實例數量
五、總結
在App的世界裏,功能層面的差異已經越來越難以體現。在這種情況下,良好的用戶體驗,往往是App致勝的關鍵。而Abort問題對於每一個App而言,都是對用戶體驗的最大挑戰,需要App開發者給予足夠的重視。
爲了更好地發現解決崩潰問題,構建異常“感知-定位-恢復”的運維能力閉環,提升 App 使用體驗,建議接入阿里雲崩潰分析,支持各類異常事件採集,支持現場回溯分析,幫助您更好的提高iOS App穩定性。