當乙個ios應用程式崩潰時，系統會建立乙份crash日誌儲存在裝置上。這份crash日誌記錄著應用程式崩潰時的資訊，通常包含著每個執行執行緒的棧呼叫資訊（低記憶體閃退日誌例外）。
方式1開發、測試階段裝置就在身邊，可以連線裝置，開啟xcode - window - devices - view device log 能夠看到裝置上的崩潰資訊，但是如果缺少符號化崩潰日誌的必要檔案時，可能導致xcode無法完成符號化的操作，而且預設是對所有的崩潰資訊進行操作，如果長時間未進行這樣的檢視操作，這個符號化的過程會花費較長時間。對於著急解決問題的情況，顯然有些捉急，這時我們應該自己找到想要符號化的.crash檔案，手動進行這一操作。
方式2！符號化的過程中我們需要三個檔案： .ipa .crash .dsym 三者缺一不可，同時需要依賴xcode的符號化工具——symbolicatecrash 下面我們對每乙個檔案的查詢及工具的使用進行說明
裝置與電腦上的itunes store同步後，會將崩潰日誌儲存在電腦上。根據電腦作業系統的不同，崩潰日誌將儲存在以下位置:
mac os x:~/library/logs/crashreporter/mobiledevice/
```
* 3>.dsym檔案
* 4> symbolicatecrash工具將我們前面準備好的三個檔案及symbolicatecrash放在桌面的同乙個資料夾中，用終端進入 這個目錄 然後 用輸入終端命令這時候終端可能會報錯error: "developer_dir" is not defined at /usr/local/bin/symbolicatecrash line 53. "
這時候在終端中再輸入如下命令:
然後再跑一下剛剛的那個命令，這時候看一下桌面的directory資料夾下就會多出乙個名為「output.crash」的檔案，我們開啟看一下。
（1）process information
這部分給出了程序crash後的部分資訊
- incident identifier crash報告的唯一標識
- crashreporter key crash報告對映到device identifier的唯一鍵值（key）。表面上看上去沒有任何含義，但實際上給我們提供了乙個有用資訊，假如我們所獲得的大量crash log擁有同樣的crashreport key，一定程度上說明這個crash問題並不是普遍存在，也許只是對一些特定的裝置存在。
（3）exception
這部分給出了crash的異常型別，異常錯誤碼和丟擲異常的執行緒。（5）thread state
這部分給出了crash時暫存器中的值。事實上，堆疊記錄已經提供了類似的資訊。這部分列出了crahs時載入的所有檔案。iOS日誌及崩潰抓取
在日常開發及測試中很容易出現比較難以復現的崩潰，這種bug往往讓我們無處下手，日誌抓取幫我們很好的解決了這個問題。ddlog的使用 首先可以在pc 件中定義log等級 static const ddloglevel ddloglevel ddloglevelverbose ddttylogger，你...
IOS崩潰日誌
1.普通崩潰日誌 參考 1 程序資訊 incident identifier 30e46451 53fd 4965 896a 457fc11ad05f 崩潰報告的唯一識別符號 是與裝置標識相對應的唯一鍵值。雖然它不是真正的裝置識別符號，但也是乙個非常有用的情報 如果你看到100個崩潰日誌的crash...
iOS專案崩潰日誌採集與分析
先看乙個下demo nsstring str nil nsarray arr hello str 很簡單，因為陣列裡面有nil元素，所以執行的時候一定會崩潰，執行的崩潰畫面分析 先看乙個oc的ddemo工程 nsstring str nil nsarray arr hello str 很簡單，因為陣...