iOS Abort問題系統性解決方案

一、背景

崩潰(Crash),即閃退,多指移動設備(如iOS、Android設備)在打開/使用應用程序的過程中,突然出現意外退出/中斷的情況。如果App線上版本頻繁發生崩潰,會極大地影響用戶體驗,甚至導致用戶流失,以及收益減少。因此,崩潰問題是客戶端穩定性團隊需要重點解決的問題。

然而,對於所有崩潰場景,僅25%的崩潰可通過信號量捕獲,實施相應改進;另有75%的崩潰則難以識別,從而對App的用戶體驗,造成了巨大的潛在影響。

image

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問題數據的總體視圖:

image

由於Abort問題出現之前,內存、CPU使用量正常,因此初步判斷造成異常退出的原因爲主線程死鎖。

image

查看相關日誌文件,驗證時間、線索吻合,因此可最終確定造成異常退出的原因爲主線程死鎖。

image

四、Abort問題的系統性解決方案

4.1 Abort系統性解決方案難點:現場捕獲
爲實現Abort問題的系統性解決方案,需充分考慮以下問題:
1.通過signal 9殺死進程造成的Abort問題,往往難以通過信號量捕獲至堆棧。在這種情況下,應如何儘可能完整地捕獲崩潰現場的關鍵信息?具體包含哪些信息?
2.App崩潰時系統處於極不穩定的狀態,應如何保證崩潰現數據穩定落盤?
3.在信息採集、數據捕獲的過程中,需對大量數據進行寫入操作,應如何保證日誌高性能寫入?
4.在數據量較大的情況下,數據的存儲、上傳可能對系統造成較大壓力,應如何保證數據的高壓縮率?

image

基於以上考慮,我們提出並設計了一套基於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實例數量

image

五、總結

在App的世界裏,功能層面的差異已經越來越難以體現。在這種情況下,良好的用戶體驗,往往是App致勝的關鍵。而Abort問題對於每一個App而言,都是對用戶體驗的最大挑戰,需要App開發者給予足夠的重視。
爲了更好地發現解決崩潰問題,構建異常“感知-定位-恢復”的運維能力閉環,提升 App 使用體驗,建議接入阿里雲崩潰分析,支持各類異常事件採集,支持現場回溯分析,幫助您更好的提高iOS App穩定性。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章