iOS Crash 流程化1：一般的 Crash 日志解析方法

  • iOS Crash 流程化：一般的 Crash 日志解析方法
    • TL;DR
    • 一、手動解析 Crash 日志
      • 1、需要的相關文件路徑or獲取途徑
        • Crash Log獲取
        • dSYM路徑
        • Symbolicatecrash的文件（已提供）路徑：
      • 2、UUID校驗（確保文件之間彼此正確對應）
        • .crash
        • dSYM
        • .App
      • 3、.Crash文件分析過程
    • 二、通過Xcode查看設備崩潰信息
    • 三、使用 Apple 提供的 Crash 崩潰收集服務
      • 1、上報錯誤信息
      • 2、查看崩潰次數
      • 3、回到 Xcode 查看
        • 查看具體崩潰信息
    • 四、第三方崩潰分析工具 Bugly
      • 沖突
    • 補充：來自iOS知識小集
    • Ref

默認 Build Settings -> Build Options -> Debug Information Format 中，置為了 DWARF，如果選為DWARF則不會產生dSYM文件，必須選擇DWARF with dSYM File才會生成符號表文件。

TL;DR

1、校驗Crash Log uuid

grep "ShanLinExample arm" *.crash

2、校驗dSYM uuid

dwarfdump --uuid ShanLinExample.App.dSYM/Contents/Resources/DWARF/ShanLinExample

3、校驗App uuid

dwarfdump --uuid Payload/ShanLinExample.app/ShanLinExample

4、將 Crash Log、dSYM、App 放在同一個文件夾下，符號化

./symbolicatecrash ShanLinExample-2016-06-14-133332.crash ShanLinExample.App.dSYM > report.log

一、手動解析 Crash 日志

1、需要的相關文件路徑or獲取途徑

Crash Log 獲取
  1. 將發生了Crash的手機連接電腦，打開Xcode-菜單欄Window-Devices and Simulators
  2. 打開相應的手機View Device Logs
    image
  3. 建議按時間倒序排列，選中相應App的CrashLog，右鍵Export Log，以桌面CrashReport文件夾為例拷貝到~/Desktop/CrashReport
    image
dSYM路徑

每一個打包版本都有個對應的 Archives 文件，路徑為：

~/Library/Developer/Xcode/Archives
  1. Xcode-菜單欄Window-Archives選中相應版本Archive-show in Finder
    image
  2. 對選中.xcarchive右鍵顯示包內容，在dSYMs文件夾下找到#AppName#.app.dSYM，拷貝到桌面CrashReport文件夾中
    image
Symbolicatecrash的文件（已提供）路徑：
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

Xcode不同版本間Symbolicatecrash的位置可能會有差異，如DVTFoundation.framework部分文件名不一樣。

若找不到可以通過命令來查找：

find /Applications/Xcode.App -name symbolicatecrash -type f

2、UUID校驗（確保文件之間彼此正確對應）

Ps. ShanLinExample改為對應的AppName即可。

.crash
grep "ShanLinExample arm" *.crash

輸出結果：

0x100054000 - 0x1008e3fff ShanLinExample arm64  <f960888bef2430e9b844732364819642> /var/containers/Bundle/Application/84FA640D-AC63-4848-9989-9C5D8FCA748A/ShanLinExample.app/ShanLinExample
dSYM
dwarfdump --uuid ShanLinExample.App.dSYM/Contents/Resources/DWARF/ShanLinExample

輸出結果：

UUID: 271C3816-D14F-3FFE-93FA-D0A8F2912DF0 (armv7) ShanLinExample.App.dSYM/Contents/Resources/DWARF/ShanLinExample
UUID: F960888B-EF24-30E9-B844-732364819642 (arm64) ShanLinExample.App.dSYM/Contents/Resources/DWARF/ShanLinExample
.App

應用Archive生成的.ipa，將后綴改為.zip，解壓生成Payload文件夾，里面有個與App同名文件，此時用命令行：

dwarfdump --uuid Payload/ShanLinExample.app/ShanLinExample

輸出結果：

UUID: 271C3816-D14F-3FFE-93FA-D0A8F2912DF0 (armv7) Payload/ShanLinExample.app/ShanLinExample
UUID: F960888B-EF24-30E9-B844-732364819642 (arm64) Payload/ShanLinExample.app/ShanLinExample

對比UUID即可。

圖例

3、.Crash文件分析過程

將Symbolicatecrash、dSYM文件、.crash文件都放在一個文件夾中，例如~/Desktop/CrashReport

先運行：

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

否則會報錯：

Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 60.

輸入命令:

./symbolicatecrash ShanLinExample-2016-06-14-133332.crash ShanLinExample.App.dSYM > report.log

則最終生成的report.log文件即為崩潰時的具體信息。

二、通過Xcode查看設備崩潰信息

可以將發生崩潰的設備連接Xcode，選擇window－> devices －> 選擇自己的手機 -> view device logs 就可以查看手機上所有的崩潰信息了。

image

只要手機上的應用是這臺電腦安裝打包的，這樣的崩潰信息系統已經為我們符號化好了，只需要進去之后等一會就行。如果還是沒有符號化完畢 ，可以選擇文件，然后右擊選擇Re-Symbolicate就可以。

如果是使用其他電腦進行的打包，可以在這里面將Crash文件導出，自己通過命令行的方式進行解析。

三、使用 Apple 提供的 Crash 崩潰收集服務

1、上報錯誤信息

App上線以后蘋果就會自動捕捉崩潰信息，當 App 出現 Crash 后iOS系統就會記錄崩潰日志并上傳到Apple的服務器。前提是需要用戶同意 “與應用開發者共享”：

設置->隱私->診斷與用量->與應用開發者共享

2、查看崩潰次數

上線運行一段時間后就可以登錄iTunes Connect查看。登錄后點擊 App 分析 --> 選擇要查看的App --> 點擊右下角的崩潰，就可以根據篩選條件確定Crash的版本和日期。

確定完版本和日期后并不能在iTunes Connect中查看崩潰日志。具體信息還要回到Xcode中完成。

3、回到 Xcode 查看

查看具體崩潰信息

Xcode打開App，選擇Window->Organizer，選擇右邊的Crashes

Organizer
Crashes
崩潰信息

這里選擇具體的線上版本，崩潰信息就出現了（此時需要聯網）

image

UIKit 開頭是應該是無法定位的錯誤，哪兒紅兒哪一行就是錯誤信息。這里的錯誤實際是因為使用UIScrollview的Category進行鍵盤隱藏而產生的Crash。當使用中文手寫鍵盤輸入就會出現這種情況。

可定位的錯誤信息如下，點擊箭頭選擇App打開就會打開Xcode，然后把當時的線程和堆棧呈現出來。


可定位錯誤
在項目中查看

在項目中查看最好恢復到發布時候的版本。代碼保持一致性。有時候項目中查看定位并不準確，但是有這些當時崩潰的線程，還是有助于我們定位錯誤的。

注意: 官方提供的崩潰信息并不是實時的，只能查看兩天之前的崩潰信息。需要實時的可以使用第三方工具。

四、第三方崩潰分析工具 Bugly

有很多第三方工具可以進行崩潰統計分析，個人比較推薦 Bugly（不推薦友盟，網易云捕和國外的 Crashlytics 都沒有用過）。它的優勢在于，可以直接將崩潰信息分析出來并且做好分類和匯總。當然完整的解析崩潰需要上傳dSYM到Bugly后臺，可以通過手動上傳的方式，也可以按照 Bugly 的文檔配置腳本進行上傳。

image

這就是Bugly的頁面，出錯堆棧Bugly會幫我們解析好，并且會根據不同情況給一些解決建議。

Bugly有一個頁面追蹤功能，這是我認為非常有用的一個功能。這個功能會將用戶在不同頁面之間跳轉的流程記錄下來。這樣對于復現bug是很有用的，可以根據用戶頁面跳轉推測出用戶大概操作流程，根據這個流程復現bug。

image

Bugly還有日報功能，可以每天匯總一篇日報，并且發到團隊每個人的郵箱和微信號上。

image

沖突

如果多個 Crash 收集框架存在時，往往會存在沖突。

不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應該是先判斷是否有前者已經注冊了 handler，如果有則應該把這個 handler 保存下來，在自己處理完自己的 handler 之后，再把這個 handler 拋出去，供前面的注冊者處理。這里給出相應的 Demo，Demo 由@zerygao提供。

typedef void (*SignalHandler)(int signo, siginfo_t *info, void *context);

static SignalHandler previousSignalHandler = NULL;

+ (void)installSignalHandler {
    struct sigaction old_action;
    sigaction(SIGABRT, NULL, &old_action);
    if (old_action.sa_flags & SA_SIGINFO) {
        previousSignalHandler = old_action.sa_sigaction;
    }

    LDAPMSignalRegister(SIGABRT);
    // .......

}
static void LDAPMSignalRegister(int signal) {
    struct sigaction action;
    action.sa_sigaction = LDAPMSignalHandler;
    action.sa_flags = SA_NODEFER | SA_SIGINFO;
    sigemptyset(&action.sa_mask);
    sigaction(signal, &action, 0);
}
static void LDAPMSignalHandler(int signal, siginfo_t* info, void* context) {
    //  獲取堆棧，收集堆棧
    ........

    LDAPMClearSignalRigister();

    // 處理前者注冊的 handler
    if (previousSignalHandler) {
        previousSignalHandler(signal, info, context);
    }
}

上面的是一個處理 Signal handler 沖突的大概代碼思路，下面是 NSException handler 的處理思路，兩者大同小異。

static NSUncaughtExceptionHandler *previousUncaughtExceptionHandler;

static void LDAPMUncaughtExceptionHandler(NSException *exception) {
    // 獲取堆棧，收集堆棧
    // ......
    //  處理前者注冊的 handler
    if (previousUncaughtExceptionHandler) {
        previousUncaughtExceptionHandler(exception);
    }
}

+ (void)installExceptionHandler {
    previousUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
    NSSetUncaughtExceptionHandler(&LDAPMUncaughtExceptionHandler);
}

補充：來自iOS知識小集

1、自己設備上 Xcode 編譯的包發生閃退：連上手機打開 Xcode，cmd+shift+2 呼出 Device 的 Window，如圖1所示，然后點擊 View Device Logs，然后選中對應時間段自己 app 的崩潰日志。如果此時對應的調用棧還沒有符號化，可以選中日志后右鍵如圖2所示 Re-Symbolicate Log 即可。

2、如果是打包服務器或者 Appstore 的包發生閃退：拷貝對應的包和 dSYM 到任意文件夾下，注意將 dSYM 解壓以及 .ipa 里面的 .app 取出。然后按照情況1的方式處理即可，Xcode 會自動索引二進制及 dSYM。

  • 如果APP是自己電腦編譯生成的，Xcode會根據spotlight自動找到對應的符號文件
  • 如果不是自己電腦編譯生成的，只需要將.app和dSYM放入同一文件夾，然后手動生成索引，這樣Xcode也能找到。在命令行中輸入如下命令手動創建索引：
# mdimport ,導入文件到datastore（import file hierarchies into the metadata datastore）。
mdimport pathName

上面兩種方式確保了Xcode能依據UUID找到地址對應的符號文件，這樣，Xcode就能解析出崩潰日志。

3、如果拿到別的設備導出的未符號化的崩潰日志，可以將日志拖至下圖所示的列表中，注意此時上面 tab 記得選 All Logs 而不是 This Device，然后參考情況2，找到崩潰日志對應的二進制包和 dSYM 文件，按照情況2處理即可。可能會遇到系統庫的一些方法無法符號化的問題，只需要找到對應的設備連上電腦，讓 Xcode 讀取一遍該設備(同機型和系統版本的也可以)的符號表，然后再 Re-Symbolicate 一遍就行。


image

4、遇到線上用戶崩潰，無法拿到完整崩潰日志，可以讓用戶到【設置->分析->分析數據】里面找到對應時間點的崩潰日志，然后截圖，根據一個開源工具 dSYMTools，把崩潰棧的關鍵地址輸入到文本框中即可解析出崩潰的那個方法，具體使用方法參考 answer-huang/dSYMTools: dSYM analyze

Ref

iOS開發技巧－崩潰分析

iOS查看線上App崩潰信息及第三方Crash監控

iOS Crash 捕獲及堆棧符號化思路剖析

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • 什么是符號表？ 符號表是內存地址與函數名、文件名、行號的映射表。符號表元素如下所示： <起始地址> <結束地址> ...
    深圳陽光閱讀 12,246評論 28贊 5
  • 本文就捕獲iOS Crash、Crash日志組成、Crash日志符號化、異常信息解讀、常見的Crash五部分介紹。...
    xukuangbo_閱讀 1,597評論 0贊 0
  • Determining Whether a Crash Report is Symbolicated（決定是否符號...
    helinyu閱讀 1,450評論 0贊 1
  • 人生的悲傷，有一些是無法說出口的，比如“子欲養而親不待”，我們都怕失去我們的親人，比如，只要夢見父親或者母親去世，...
    e4b685b8fdc5閱讀 150評論 1贊 2
  • 我喜歡數字7 是因為你對我說過 七年之后我們結婚
    北愛七年閱讀 179評論 0贊 0