• 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. 將發(fā)生了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查看設備崩潰信息

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

image

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

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

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

1、上報錯誤信息

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

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

2、查看崩潰次數

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

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

3、回到 Xcode 查看

查看具體崩潰信息

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

Organizer

Crashes

崩潰信息

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

image

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

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

可定位錯誤

在項目中查看

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

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

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

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

image

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

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

image

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

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

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

• 如果APP是自己電腦編譯生成的，Xcode會根據spotlight自動找到對應的符號文件
• 如果不是自己電腦編譯生成的，只需要將.app和dSYM放入同一文件夾，然后手動生成索引，這樣Xcode也能找到。在命令行中輸入如下命令手動創(chuàng)建索引：

# mdimport ,導入文件到datastore（import file hierarchies into the metadata datastore）。
mdimport pathName

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

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

image

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

Ref

iOS開發(fā)技巧－崩潰分析

iOS查看線上App崩潰信息及第三方Crash監(jiān)控

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