轉自：http://www.jianshu.com/p/12a2402b29c2
一、crash log的獲取
當你的app 在手機上crash的時候，會在手機上自動生成一個崩潰日誌，也就是我們說的Crash Log。
CrashLog的位置位於:
iPhone設備的var/mobile/Library/Logs/CrashReporter
我們要獲取的就是設備中的這個CrashLog。
1、獲取用戶的 crash log
注意。這裏的用戶指的是你的app已經上架到AppStore上後的用戶。
作爲開發者，你想要獲取到你的用戶的崩潰日誌的話就得通過 iTunes Connect 了。在iTunes Connect 上的 Manage
Your Applications -> View Details -> Crash Reports
這種方式有個前提，就是用戶設備同意上傳相關信息，打開了診斷與用量這個選項
設置->隱私->診斷與用量（由於筆者還未有app上架，所以這個方法筆者未用過，so 就此打住。 希望有用過的大牛來拍磚或者補充，Thx）
2、獲取測試機的crash log
很多測試人員在測試途中，或者開發者在自測的途中，會遇到APP crash的情況。
一般的bug，一個合格的測試可以給出明確的重現步驟讓開發者清晰地知道bug原因；
也有不少bug，很多時候是偶現的，很可能無法再次重現出來，無法重現出來的bug是開發者頭疼的，測試一般會給出bug的截圖和重現步驟；
而一般crash是比較嚴重的問題了（所以千萬不能當什麼都沒發生過，不然會被打的233），這個時候崩潰日誌就尤爲重要了，把崩潰日誌send給開發人員，如此才能讓開發者快速定位到錯誤的原因和位置。
那麼測試如何拿到crash日誌呢？
方法一：連接電腦，通過iTools高級選項來獲取崩潰日誌（Mac版的找不到高級選項T.T，望賜教補充）
方法二：連接電腦，去本地目錄找
Mac : ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
Windows : C://Users/<USERNAME>/AppDataRoamingApple/ComputerLogsCrashReporterMobileDevice/<DEVICE_NAME>/
這個時候你會發現一大堆的.crash文件和.ips文件
方法三：通過Xcode獲取到崩潰日誌，方法是Xcode->Window->Devices
二、Crash Log的符號化
獲取到了.crash或者.ips文件的時候(憋糾結這兩個文件有什麼差，改下後綴名就ok)，用文本編輯器打開文件是一堆十六進制的內存地址，你會鬱悶的發現壓根看不懂。
Q:十六進制內存地址可以改成看得懂的麼？
A：當然，將這些十六進制地址轉化成方法名稱和行數的過程稱之爲Symbolication（符號化）。符號化很簡單，只要你把你的.crash文件拉到上面提到過的Xcode的device log裏面，然後幾秒鐘後就會符號化。但是這裏有個前提，就是這個發生crash的版本包必須是你自己的Xcode裏面Archive出來的（這個是蘋果自帶的方法，會自動檢測是否含有匹配的.dSYM文件和應用二進制文件）。
Q：那如果要是在新電腦上也想符號化怎麼辦？
答案是，只有相匹配的.dSYM文件和應用二進制文件就可以符號化。必需完全匹配纔行。否則，日誌將無法被完全符號化。
上圖是.dSYM文件的位置，應用的二進制文件就是打的包得.ipa後綴改成.zip，然後解壓后里面有個.app文件就是應用的二進制文件。
將.dSYM文件與.app文件 和crash文件放一個目錄下，然後再用deviceLog方法就可以符號化了。
另外還有另外符號化iOS Crash文件的3種方法有大牛已經整合得非常好了，給個鏈接，這裏就不贅述了。
符號化以後是這樣的~
這樣看上去就倍兒爽了^_^
三、Crash Log的分析
接下來就讓我們對已經符號化以後的crash文件進行分析。
網上已有的分類比較多，我這裏直接把我目前一般找crash原因的模塊展示出來，其他的就留待各位自己去研究了，分別是設備和crash信息、異常信息、線程信息
1、首先是設備和crash信息
Incident Identifier: F3573A...E2F244A //crash的id
CrashReporter Key: cc2298...es77eeb //crash的設備id
Hardware Model: iPhone7,2 //手機型號
Process: [AppName] [1816] //APP的名字[進程的id]
Path: /private/.../Application... //APP的位置
Identifier: com.... //bundle ID
Version: 14 (2.3.5) //版本號
Code Type: ARM-64 (Native) //app的應用架構之類不大清楚，^_^
Parent Process: launchd [1]
Date/Time: 2015-10-26 15:03:29.29 +0800 //crash發生時間
Launch Time: 2015-10-26 14:58:28.28 +0800 //進入應用時間
OS Version: iOS 9.1 (13B143) //iOS版本
Report Version: 105當你有大量的crash文件的時候，你就可以對crash文件裏面的 Hardware Model，Version ， OS Version等進行分類，就可以獲知到很多信息，比如說，你會知道crash一般發生原因是因爲手機型號，還是App版本，或者還是手機版本的原因。（筆者暫時沒碰過大量的crash文件，所以只能紙上談兵了^_^）
2、其次是異常信息
Exception Type: EXC_BAD_ACCESS (SIGABRT) //異常的類型
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000118 //異常子類型
Triggered by Thread: 0 //異常發生的線程(0爲主線程，其他爲子線程)3、線程信息
Last Exception Backtrace:
0 CoreFoundation 0x182780f48 __exceptionPreprocess + 124
1 libobjc.A.dylib 0x197333f80 objc_exception_throw + 56
2 CoreFoundation 0x182780e90 +[NSException raise:format:] + 120
3 [AppName] 0x100c42a40 UmengSignalHandler + 144
4 libsystem_platform.dylib 0x197d6193c _sigtramp + 52
5 [AppName] 0x1005d9f38 CScopePtr<IAVGAudioLogic>::operator IAVGAudioLogic*<IAVGAudioLogic>() (xprefc.h:165)
6 [AppName] 0x1005d3b8c tencent::av::AVRoomMultiImpl::GetAudioLogic() (av_room_multi_impl.h:119)
7 [AppName] 0x10057076c tencent::av::AVAudioCtrlImpl::SetAudioOutputMode(int) (av_audio_ctrl_impl.cpp:443)
8 [AppName] 0x10044dc3c -[AVBasicManager changeSpeakerMode:] (AVManager.mm:525)
9 [AppName] 0x100296e1c -[KTQAVRoom enableSpeakerMode:] (KTQAVRoom.m:345)
10 [AppName] 0x1002970d0 -[KTQAVRoom settingSpeaker:] (KTQAVRoom.m:362)
11 [AppName] 0x1003d5464 -[KTChatView onAudioNotificationReceived:] (KTChatView.m:685)恩。。。這符號化以後應該可以看懂了吧，這個crash的問題應該是騰訊第三方的一個衝突吧233
一般來說，通過異常信息和線程信息就可以找到crash的原因了。
補充一些異常類型信息
這裏參考了很多信息，有很多的異常類型，有些沒遇到過，這裏就厚顏摘抄過來了（這裏是原文地址：iOS Crash文件的解析，再次感謝大牛們的經驗）
1、Exception Type
1）EXC_BAD_ACCESS
此類型的Excpetion是我們最長碰到的Crash，通常用於訪問了不改訪問的內存導致。一般EXC_BAD_ACCESS後面的"()"還會帶有補充信息。
SIGSEGV: 通常由於重複釋放對象導致，這種類型在切換了ARC以後應該已經很少見到了。
SIGABRT: 收到Abort信號退出，通常Foundation庫中的容器爲了保護狀態正常會做一些檢測，例如插入nil到數組中等會遇到此類錯誤。
SEGV:（Segmentation Violation），代表無效內存地址，比如空指針，未初始化指針，棧溢出等；
SIGBUS：總線錯誤，與 SIGSEGV 不同的是，SIGSEGV 訪問的是無效地址，而 SIGBUS 訪問的是有效地址，但總線訪問異常(如地址對齊問題)
SIGILL：嘗試執行非法的指令，可能不被識別或者沒有權限
2）EXC_BAD_INSTRUCTION
此類異常通常由於線程執行非法指令導致
3）EXC_ARITHMETIC
除零錯誤會拋出此類異常
2、Exception Code
0xbaaaaaad 此種類型的log意味着該Crash log並非一個真正的Crash，它僅僅只是包含了整個系統某一時刻的運行狀態。通常可以通過同時按Home鍵和音量鍵，可能由於用戶不小心觸發
0xbad22222 當VOIP程序在後臺太過頻繁的激活時，系統可能會終止此類程序
0x8badf00d 程序啓動或者恢復時間過長被watch dog終止
0xc00010ff 程序執行大量耗費CPU和GPU的運算，導致設備過熱，觸發系統過熱保護被系統終止
0xdead10cc 程序退到後臺時還佔用系統資源，如通訊錄被系統終止
0xdeadfa11 前面也提到過，程序無響應用戶強制關閉
總結
最後總結一些可能會對各位有用的博文：
1、iOS應用崩潰日誌分析(這最後有一個栗子很有意思)
2、獲取 iOS crash log(分析得很詳細)
3、WWDC視頻(2010年的WWDC視頻)
4、官網文檔——Analyzing iOS Application Crash Reports
最最後得PS下：筆者用的是Xcode7.1+iOS9.1