前言

作為一個程序開發人員，調試程序編寫過程中遇到的各種異常奔潰，是再常見不過的現象了。一般在開發過程中，我們可以通過打斷點、輸出log等多種方式來調試我們的程序。在iOS開發調試完上線之后，程序仍然會出現崩潰的問題（盡管我們已經盡量做到在上線之前解決遇到的一切問題，但是線上崩潰問題，我們仍然不可避免o(╯□╰)o）。簡單的崩潰還好說，但是復雜的奔潰就需要我們通過crash文件來分析了，解析Crash文件在iOS開發過程的不可避免的。由于今天遇到了，自己也查了一些相關資料，做了一些相關了解（原諒本人開發資歷尚淺）。這里記錄一下，iOS對APP線上Crash現象的調試（主要是Crash信息的收集，然后作出相應的處理）。線下的lldb斷點log調試，你們可以查閱這兩篇文章
NSLog效率低下的原因及嘗試lldb斷點打印Log
XCODE LLDB TUTORIAL

獲取崩潰信息

這里首先說明一下收集崩潰信息的幾種方式

• 自己實現應用內崩潰收集，并上傳服務器。
• Xcode-Devices中直接查看某個設備的崩潰信息。
• 使用蘋果提供的Crash崩潰收集服務。
• 使用友盟、百度等第三方崩潰統計工具。
  下面就詳細說說這四種方式

第一種、自己實現應用內崩潰收集，并上傳服務器

蘋果給我們提供了異常處理的類，NSException類。這個類可以創建一個異常對象，也可以通過這個類獲取一個異常對象。這個類中我們最常用的還是一個獲取崩潰信息的C函數，我們可以通過這個函數在程序發生異常的時候收集這個異常，在程序再次啟動的時候上傳到我們的服務器。這里貼出代碼:

// 將系統提供的獲取崩潰信息函數寫在這個方法中，以保證在程序開始運行就具有獲取崩潰信息的功能 
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{ 
    // 將下面C函數的函數地址當做參數 
    NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
    return YES;
 } 
// 設置一個C函數，用來接收崩潰信息
void UncaughtExceptionHandler(NSException *exception)
{ // 可以通過exception對象獲取一些崩潰信息，我們就是通過這些崩潰信息來進行解析的，例如下面的symbols數組就是我們的崩潰堆棧。 
    NSArray *symbols = [exception callStackSymbols]; 
    NSString *reason = [exception reason]; 
    NSString *name = [exception name]; 
}

這種自己收集奔潰信息上傳自己服務器的方式，是我現在做的項目所采取的方式。優點是：高度自定義，可以上傳自己想要的一切信息。但是現在發現一個問題就是收集的信息對于開發人員來說，幫助有限。如圖：

Paste_Image.png

• 符號集是我們對ipa文件進行打包之后，和.app文件同級的后綴名為.dSYM的文件，這個文件必須使用Xcode進行打包才有。
• 每一個.dSYM文件都有一個UUID，和.app文件中的UUID對應，代表著是一個應用。而.dSYM文件中每一條崩潰信息也有一個單獨的UUID，用來和程序的UUID進行校對。
• 我們如果不使用.dSYM文件獲取到的崩潰信息都是不準確的。
• 符號集中存儲著文件名、方法名、行號的信息，是和可執行文件的16進制函數地址對應的，通過分析崩潰的.Crash文件可以準確知道具體的崩潰信息。

我們每次Archive一個包之后，都會隨之生成一個dSYM文件。每次發布一個版本，我們都需要備份這個文件，以方便以后的調試。進行崩潰信息符號化的時候，必須使用當前應用打包的電腦所生成的dSYM文件，其他電腦生成的文件可能會導致分析不準確的問題。當程序崩潰的時候，我們可以獲得到崩潰的錯誤堆棧，但是這個錯誤堆棧都是0x開頭的16進制地址，需要我們使用Xcode自帶的symbolicatecrash工具來將.Crash和.dSYM文件進行符號化，就可以得到詳細崩潰的信息。

第二種、Xcode-Devices中直接查看某個設備的崩潰信息

崩潰分析

命令行解析Crash文件

• symbolicatecrash，Xcode自帶的崩潰分析工具，使用這個工具可以更精確的定位崩潰所在的位置，將0x開頭的地址替換為響應的代碼和具體行數。
• 我們打包時產生的dSYM文件。
• 崩潰時產生的Crash文件。

我在解析崩潰信息的時候，首先在桌面上建立一個Crash文件夾，然后將.Crash、.dSYM、symbolicatecrash放在這個文件夾中，這樣進入這個文件夾下，直接一行命令就解決了。
symbolicatecrash我們可以在下面路徑下可以找到，我用的是Xcode7，其他版本Xcode路徑不一樣，請自行Google。
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
如何獲取字符集
***第一步：打開 Xcode，選擇"Window——>Organizer"

FlAeqMZUGDTcPzVHmx9prx6gxvC3.png

FrkVrxPkRsn3eh9C8ZRNhRSoVx3z.png

FnOHevdMzwjb3oygeIETYmgWjd_l.png

Fn8UzEMe-Zq72lY0JOQ0vE6AzR8t.png

1. 如果建立的項目是用于搜集 Apple Watch 或者 App Extension的崩潰，dSYMs 文件夾下會有多個 dSYM 文件，可以根據 dSYM 文件的尾綴來區分符號表:
   Apple Watch 的 dSYM 文件尾綴是 “AppName WatchKit Extension.appex”
   App Extension 的 dSYM 文件尾綴是“AppExtensionName.appex.dSYM”

2. 如果發現這個位置沒有 dSYM 文件，說明你的打包配置設置了打包時不生成符號表。可查看Build Settings -> Build Options -> Debug Information Format 的設置，如果選為DWARF則不會產生dSYM文件，必須選擇DWARF with dSYM File才會生成符號表文件。

第五步：Contents/Resources/DWARF 文件夾下的文件即為要上傳的符號表

FnrgD8QYEFd4Jpmt4hPyCSAS52Qr.png

將.Crash、.dSYM、symbolicatecrash三個文件都放在我們在桌面建立的Crash文件夾中。

開啟命令行工具，進入崩潰文件夾中
cd /Users/username/Desktop/崩潰文件夾
使用命令解析Crash文件
./symbolicatecrash ./.crash ./.app.dSYM > symbol.crash
如果上面命令不成功，使用命令檢查一下環境變量
xcode-select -print-path
返回結果：
/Applications/Xcode.app/Contents/Developer/

如果不是上面的結果，需要使用下面命令設置一下導出的環境變量，然后重復上面解析的操作。
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
解析完成后會生成一個新的.Crash文件，這個文件中就是崩潰詳細信息。圖中紅色標注的部分就是我們代碼崩潰的部分。

解析完成后會生成一個新的.Crash文件，這個文件中就是崩潰詳細信息。圖中紅色標注的部分就是我們代碼崩潰的部分。

解析完成的結果

注意，以下情況不會有崩潰信息產生：

• 內存訪問錯誤(不是野指針錯誤)
• 低內存，當程序內存使用過多會造成系統低內存的問題，系統會將程序內存回收
• 因為某種原因觸發看門狗機制

第三種、使用蘋果提供的Crash崩潰收集服務

除了上面的系統分析工具來進行分析，如果是我們自己直接使用手機連接崩潰或者崩潰之后連接手機，選擇window－> devices －> 選擇自己的手機 -> view device logs 就可以查看我們的崩潰信息了。

view device logs

只要手機上的應用是這臺電腦安裝打包的，這樣的崩潰信息系統已經為我們符號化好了，我們只需要進去之后等一會就行(不要相信這里面的進度刷新，并不準確)，如果還是沒有符號化完畢 ，我們選擇文件，然后右擊選擇Re-Sysbomlicate就可以。
如果是使用其他電腦進行的打包，我們可以在這里面將Crash文件導出，自己通過命令行的方式進行解析。

第四種、使用友盟、百度等第三方崩潰統計工具

友盟統計
BugHD
附上幾張BugHD 的示例圖

Paste_Image.png

Paste_Image.png

Paste_Image.png

本文也是本人學習之互聯網，并用作筆記之用。貼出借鑒之出處iOS開發技巧－崩潰調試