一、背景

崩潰(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: 0Application Specific Information: com.myapp.myapp failed to scene-create in timeElapsed total CPU time (seconds): 4.230 (user 4.230, system 0.000), 10% CPU Elapsed application CPU time (seconds): 1.039, 3% CPUThread 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開發者給予足夠的重視。

?

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的iOS Abort问题系统性解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。