iOS Abort問題系統性解決方案

一、背景

崩潰(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:  00000020Exception Codes: 0x000000008badf00dHighlighted 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-threadThread 0:0   libsystem_kernel.dylib          0x36360540 semaphore_wait_trap + 81   libdispatch.dylib               0x36297eee _dispatch_semaphore_wait_slow + 1862   libxpc.dylib                    0x364077b8 xpc_connection_send_message_with_reply_sync + 1523   Security                        0x2b8dd310 securityd_message_with_reply_sync + 644   Security                        0x2b8dd48c securityd_send_sync_and_do + 445   Security                        0x2b8ea452 __SecItemCopyMatching_block_invoke + 1666   Security                        0x2b8e96f6 SecOSStatusWith + 147   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穩定性。

釘釘搜尋35248489，加入阿里云云原生應用研發平臺EMAS技術交流群，探討最新最熱門的應用研發技術和實踐。（或釘釘掃碼加入）

作者：淘寶廬軒