一独泞、crash log的獲取
當(dāng)你的app 在手機(jī)上crash的時候胧卤，會在手機(jī)上自動生成一個崩潰日志大莫，也就是我們說的Crash Log烈炭。
CrashLog的位置位于:
iPhone設(shè)備的var/mobile/Library/Logs/CrashReporter
我們要獲取的就是設(shè)備中的這個CrashLog。
1优妙、獲取用戶的 crash log
注意乘综。這里的用戶指的是你的app已經(jīng)上架到AppStore上后的用戶。
作為開發(fā)者套硼，你想要獲取到你的用戶的崩潰日志的話就得通過 iTunes Connect 了卡辰。在 iTunes Connect 上的 Manage Your Applications -> View Details -> Crash Reports
這種方式有個前提，就是用戶設(shè)備同意上傳相關(guān)信息，打開了診斷與用量這個選項
設(shè)置->隱私->診斷與用量（由于筆者還未有app上架九妈，所以這個方法筆者未用過反砌，so 就此打住。 希望有用過的大牛來拍磚或者補(bǔ)充萌朱，Thx）
2宴树、獲取測試機(jī)的crash log
很多測試人員在測試途中，或者開發(fā)者在自測的途中晶疼，會遇到APP crash的情況酒贬。
一般的bug，一個合格的測試可以給出明確的重現(xiàn)步驟讓開發(fā)者清晰地知道bug原因翠霍；
也有不少bug锭吨，很多時候是偶現(xiàn)的，很可能無法再次重現(xiàn)出來寒匙，無法重現(xiàn)出來的bug是開發(fā)者頭疼的零如，測試一般會給出bug的截圖和重現(xiàn)步驟；
而一般crash是比較嚴(yán)重的問題了（所以千萬不能當(dāng)什么都沒發(fā)生過锄弱，不然會被打的233）埠况，這個時候崩潰日志就尤為重要了，把崩潰日志send給開發(fā)人員棵癣，如此才能讓開發(fā)者快速定位到錯誤的原因和位置辕翰。
那么測試如何拿到crash日志呢？
方法一：連接電腦狈谊，通過iTools高級選項來獲取崩潰日志（Mac版的找不到高級選項T.T喜命，望賜教補(bǔ)充）
方法二：連接電腦，去本地目錄找
Mac : ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
Windows : C://Users/<USERNAME>/AppDataRoamingApple/ComputerLogsCrashReporterMobileDevice/<DEVICE_NAME>/
這個時候你會發(fā)現(xiàn)一大堆的.crash文件和.ips文件
方法三：通過Xcode獲取到崩潰日志河劝，方法是Xcode->Window->Devices
二壁榕、Crash Log的符號化
獲取到了.crash或者.ips文件的時候(憋糾結(jié)這兩個文件有什么差，改下后綴名就ok)赎瞎，用文本編輯器打開文件是一堆十六進(jìn)制的內(nèi)存地址牌里，你會郁悶的發(fā)現(xiàn)壓根看不懂。
Q:十六進(jìn)制內(nèi)存地址可以改成看得懂的么务甥？
A：當(dāng)然牡辽，將這些十六進(jìn)制地址轉(zhuǎn)化成方法名稱和行數(shù)的過程稱之為Symbolication（符號化）。符號化很簡單敞临，只要你把你的.crash文件拉到上面提到過的Xcode的device log里面态辛，然后幾秒鐘后就會符號化。但是這里有個前提挺尿，就是這個發(fā)生crash的版本包必須是你自己的Xcode里面Archive出來的（這個是蘋果自帶的方法奏黑，會自動檢測是否含有匹配的.dSYM文件和應(yīng)用二進(jìn)制文件）炊邦。
Q：那如果要是在新電腦上也想符號化怎么辦？
答案是熟史，只有相匹配的.dSYM文件和應(yīng)用二進(jìn)制文件就可以符號化馁害。必需完全匹配才行。否則蹂匹，日志將無法被完全符號化蜗细。
上圖是.dSYM文件的位置，應(yīng)用的二進(jìn)制文件就是打的包得.ipa后綴改成.zip怒详，然后解壓后里面有個.app文件就是應(yīng)用的二進(jìn)制文件。
將.dSYM文件與.app文件 和crash文件放一個目錄下踪区，然后再用deviceLog方法就可以符號化了昆烁。
另外還有另外符號化iOS Crash文件的3種方法有大牛已經(jīng)整合得非常好了，給個鏈接缎岗，這里就不贅述了静尼。
符號化以后是這樣的~
這樣看上去就倍兒爽了_
三、Crash Log的分析
接下來就讓我們對已經(jīng)符號化以后的crash文件進(jìn)行分析传泊。
網(wǎng)上已有的分類比較多鼠渺，我這里直接把我目前一般找crash原因的模塊展示出來，其他的就留待各位自己去研究了眷细，分別是設(shè)備和crash信息拦盹、異常信息、線程信息
1溪椎、首先是設(shè)備和crash信息
Incident Identifier: F3573A...E2F244A //crash的id
CrashReporter Key: cc2298...es77eeb //crash的設(shè)備id
Hardware Model: iPhone7,2 //手機(jī)型號
Process: [AppName] [1816] //APP的名字[進(jìn)程的id]
Path: /private/.../Application... //APP的位置
Identifier: com.... //bundle ID
Version: 14 (2.3.5) //版本號
Code Type: ARM-64 (Native) //app的應(yīng)用架構(gòu)之類不大清楚普舆，^_^
Parent Process: launchd [1]
Date/Time: 2015-10-26 15:03:29.29 +0800 //crash發(fā)生時間
Launch Time: 2015-10-26 14:58:28.28 +0800 //進(jìn)入應(yīng)用時間
OS Version: iOS 9.1 (13B143) //iOS版本
Report Version: 105
當(dāng)你有大量的crash文件的時候，你就可以對crash文件里面的 Hardware Model校读，Version 沼侣， OS Version等進(jìn)行分類，就可以獲知到很多信息歉秫，比如說蛾洛，你會知道crash一般發(fā)生原因是因為手機(jī)型號，還是App版本雁芙，或者還是手機(jī)版本的原因轧膘。（筆者暫時沒碰過大量的crash文件，所以只能紙上談兵了_）
2兔甘、其次是異常信息
Exception Type: EXC_BAD_ACCESS (SIGABRT) //異常的類型
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000118 //異常子類型
Triggered by Thread: 0 //異常發(fā)生的線程(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)
恩裂明。椿浓。太援。這符號化以后應(yīng)該可以看懂了吧，這個crash的問題應(yīng)該是騰訊第三方的一個沖突吧233
一般來說扳碍，通過異常信息和線程信息就可以找到crash的原因了提岔。
補(bǔ)充一些異常類型信息
這里參考了很多信息，有很多的異常類型笋敞，有些沒遇到過碱蒙，這里就厚顏摘抄過來了（這里是原文地址：iOS Crash文件的解析，再次感謝大牛們的經(jīng)驗）
1夯巷、Exception Type
1）EXC_BAD_ACCESS
此類型的Excpetion是我們最長碰到的Crash赛惩，通常用于訪問了不改訪問的內(nèi)存導(dǎo)致。一般EXC_BAD_ACCESS后面的"()"還會帶有補(bǔ)充信息趁餐。
SIGSEGV: 通常由于重復(fù)釋放對象導(dǎo)致喷兼，這種類型在切換了ARC以后應(yīng)該已經(jīng)很少見到了。
SIGABRT: 收到Abort信號退出后雷，通常Foundation庫中的容器為了保護(hù)狀態(tài)正常會做一些檢測季惯，例如插入nil到數(shù)組中等會遇到此類錯誤。
SEGV:（Segmentation Violation）臀突，代表無效內(nèi)存地址勉抓，比如空指針，未初始化指針候学，棧溢出等藕筋；
SIGBUS：總線錯誤，與 SIGSEGV 不同的是梳码，SIGSEGV 訪問的是無效地址念逞，而 SIGBUS 訪問的是有效地址，但總線訪問異常(如地址對齊問題)
SIGILL：嘗試執(zhí)行非法的指令边翁，可能不被識別或者沒有權(quán)限
2）EXC_BAD_INSTRUCTION
此類異常通常由于線程執(zhí)行非法指令導(dǎo)致
3）EXC_ARITHMETIC
除零錯誤會拋出此類異常
2翎承、Exception Code
0xbaaaaaad 此種類型的log意味著該Crash log并非一個真正的Crash，它僅僅只是包含了整個系統(tǒng)某一時刻的運行狀態(tài)符匾。通尺犊В可以通過同時按Home鍵和音量鍵，可能由于用戶不小心觸發(fā)
0xbad22222 當(dāng)VOIP程序在后臺太過頻繁的激活時啊胶，系統(tǒng)可能會終止此類程序
0x8badf00d 程序啟動或者恢復(fù)時間過長被watch dog終止
0xc00010ff 程序執(zhí)行大量耗費CPU和GPU的運算甸各，導(dǎo)致設(shè)備過熱，觸發(fā)系統(tǒng)過熱保護(hù)被系統(tǒng)終止
0xdead10cc 程序退到后臺時還占用系統(tǒng)資源焰坪，如通訊錄被系統(tǒng)終止
0xdeadfa11 前面也提到過趣倾，程序無響應(yīng)用戶強(qiáng)制關(guān)閉
總結(jié)
最后總結(jié)一些可能會對各位有用的博文：
1、iOS應(yīng)用崩潰日志分析(這最后有一個栗子很有意思)
2某饰、獲取 iOS crash log(分析得很詳細(xì))
3儒恋、WWDC視頻(2010年的WWDC視頻)
4善绎、官網(wǎng)文檔——Analyzing iOS Application Crash Reports
最最后得PS下：筆者用的是Xcode7.1+iOS9.1
