具體步驟
。2. 找到崩潰日誌 *.crash檔案
，如果確定直接到步驟4
3. 如果uuid相同你就可以進行下面的工作了
5. 然後用dwarfdump 命令如果運氣好就能找出對於記憶體位址在**中的位置，否則就悲慘了。（這個需要在命令列操作）
6. 最後就是找**檢視bug
ps：如果出現找不到symbolicatecrash 命令，請使用以下命令後就可以正常使用：
這個blog只是理清楚分析crash思路，具體怎麼做google上面很多。
推薦一下幾個**：
通過以上步驟大概了解怎麼分析crash檔案了吧：下面詳細一點
第一步使用起來很簡單。分三步即可。
3> 用dwarfdump檢查dsym檔案是否是上面的uuid。命令列格式：
如果三者的uuid都是一致的，那麼恭喜你，該crash log可以被正確解析出來，stack traces資訊可以被正確地拿到。
第二步
1、ios應用crash的四種型別
2、如何獲取crash log
iphone真機上crash檔案的儲存路徑為：/var/mobile/library/logs/crashreporter
我們走xcode的organizer的device log中獲取相應應用的crash資訊檔案
3、如何分析
如果您的應用程式就是由你的xcode生成，那麼自動在crash log中會對資訊進行翻譯，得到有效的crash資訊。
如果不是這樣，按下面方面處理
symbolicatecrash 命令工具的位置：
在ios3.0及以後版本，
/developer/platforms/iphoneos.platform/developer/library/privateframeworks/dtdevicekit.framework/versions/a/resources
在ios3.0以前版本，/developer/platforms/iphoneos.platform/developer /library/xcode/plug-ins/iphoneremotedevice.xcodeplugin/contents/resources/
4、crash log分析原理
5、使用其他方法分析crash
如果使用symbolicatecrash?無法定位到出錯的**行的話，怎麼整呢？有乙個辦法，如下：
首先檢視crash log中的崩潰執行緒，假如是這樣的：
thread 0 crashed:
0 libobjc.a.dylib
0x00003ec0 objc_msgsend + 24
0x000036d2 0×1000 + 9938?
當然正常情況下crash問題，我們可以在xcode下除錯分析，這種最為直接，但如果終端的ios版本過高，我們的xcode不支援，就只能公升級系統+xcode+sdk方式來進行除錯分析。
ios crash檔案分析
ios程式在真機執行程式出現crash狀況時，機器會自動產生log檔案，它包含了在程式crash之前的執行邏輯，分析carsh檔案，有效的解決程式在真機上的問題，保證程式良好的穩定性,但是這個crash檔案多數是顯示出現問題的位址和一些系統的訊息，無法檢視程式中對應的崩潰地點，以下文章幫你解決這個問...
iOS crash日誌分析
專案整合talkingdata收集到的crash日誌,看到那些日誌時自己也是很崩潰,全是記憶體位址,根本搞不懂專案到底crash到了那裡,比如這樣 自己在網上找了很多方法,以下是自己最後所用到的方法 心累 2,對.dsym檔案顯示包內容,找到dwarf資料夾 路徑 dsym contents res...
iOS Crash檔案的解析
一 crash檔案結構 當程式執行crash的時候，系統會把執行的最後時刻的執行資訊記錄下來，儲存到乙個檔案中，也就是我們所說的crash檔案。ios的crash日誌通常由以下6各部分組成。1 process information 程序資訊 incident idnetifier 崩潰報告的唯一識...