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

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

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

TL;DR

1、校驗(yàn)Crash Log uuid

grep "ShanLinExample arm" *.crash

2、校驗(yàn)dSYM uuid

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

3、校驗(yàn)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、需要的相關(guān)文件路徑or獲取途徑

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

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

~/Library/Developer/Xcode/Archives
  1. Xcode-菜單欄Window-Archives選中相應(yīng)版本Archive-show in Finder
    image
  2. 對選中.xcarchive右鍵顯示包內(nèi)容，在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校驗(yàn)（確保文件之間彼此正確對應(yīng)）

Ps. ShanLinExample改為對應(yīng)的AppName即可。

.crash
grep "ShanLinExample arm" *.crash

輸出結(jié)果：

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

輸出結(jié)果：

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

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

dwarfdump --uuid Payload/ShanLinExample.app/ShanLinExample

輸出結(jié)果：

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

先運(yùn)行：

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查看設(shè)備崩潰信息

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

image

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

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

三、使用 Apple 提供的 Crash 崩潰收集服務(wù)

1、上報錯誤信息

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

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

2、查看崩潰次數(shù)

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

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

3、回到 Xcode 查看

查看具體崩潰信息

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

Organizer
Crashes
崩潰信息

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

image

UIKit 開頭是應(yīng)該是無法定位的錯誤，哪兒紅兒哪一行就是錯誤信息。這里的錯誤實(shí)際是因?yàn)槭褂肬IScrollview的Category進(jìn)行鍵盤隱藏而產(chǎn)生的Crash。當(dāng)使用中文手寫鍵盤輸入就會出現(xiàn)這種情況。

可定位的錯誤信息如下，點(diǎn)擊箭頭選擇App打開就會打開Xcode，然后把當(dāng)時的線程和堆棧呈現(xiàn)出來。


可定位錯誤
在項目中查看

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

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

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

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

image

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

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

image

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

image

沖突

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

不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應(yīng)該是先判斷是否有前者已經(jīng)注冊了 handler，如果有則應(yīng)該把這個 handler 保存下來，在自己處理完自己的 handler 之后，再把這個 handler 拋出去，供前面的注冊者處理。這里給出相應(yīng)的 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);
}

補(bǔ)充：來自iOS知識小集

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

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

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

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

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


image

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

Ref

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

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

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

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

友情鏈接更多精彩內(nèi)容