前言
有代码的地方，就可能会有崩溃。定位崩溃问题的方法：最直接的，通过重现的步骤去调适；但是，有时候测试无法确定崩溃的步骤，或者崩溃是线上用户发生的，这些情况下，我们仍然可以通过崩溃日志，知道崩溃的原因和崩溃的代码行，从而修复问题。
- 什么是崩溃？
Application crashes: An application typically crashes when it performs an operation which is not allowed by the operating system.
Server crashes, Operating system crashes, …
- 定位崩溃原因的方法有哪些？
线索1：重现步骤
线索2：崩溃日志（知道崩溃的原因、崩溃的代码行等信息）
那么，本文就来说说崩溃日志。
获取日志的几种方法
在iOS系统中，当应用崩溃的时候，系统会生成一个崩溃日志，保存在设备上。
1.直接在手机上查看
在手机端设置里查看，如图是iOS10的界面：
2.手机连PC用iTunes导出
iTunes同步资料库，然后去PC对应目录下，找文件
Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/
Windows XP: C://Documents and Settings/Application Data/Apple Computer/Logs/Crash/Reporter/MobileDevice
Windows Vista or 7: C://Users/AppData/Roaming/Apple Computer/Logs/Crash/Reporter/MobileDevice
3.手机连XCode导出
Simulator-Hardware-Device-Manage Devices
4.XCode中，对提交商店的应用，查看Crashes
xcode->Window->Organizer->Crashes
5.用iTunes Connect（提交商店的应用）
如果应用提交到App Store了，还可以从iTunes Connect（https://itunesconnect.apple.com/）上获取到用户的崩溃日志.。通过应用提交者的apple id登录，管理提交的应用，应用细节中有一个崩溃报告
5.app植入第三方sdk，配合第三方平台查看
很多第三方平台，（比如蒲公英、fabric、网易云捕...）提供sdk和管理后台。
只需要使用它们的sdk，并添加几行代码，app运行时，sdk会将应用Crash数据自动上传到后台，后台会进行相应的统计和分析。并给出产品各个版本的崩溃数，崩溃率，影响用户数，崩溃的机型、系统 等。
6.使用苹果的api，自己实现抓取崩溃信息，提交到自己写的后台
和5是一样的，有这些现成的情况下，不是很必要自己重新再写一个，但是可以简单了解一下其中的关键原理。
1.iOS SDK中提供了一个现成的函数NSSetUncaughtExceptionHandler 用来做异常处理。
void HandleException(NSException*exception) //捕捉到异常时执行的方法
{
//异常的堆栈信息
NSArray*stackArray = [exception callStackSymbols];
//出现异常的原因
NSString*reason = [exception reason];
//异常名称
NSString*name = [exception name];
NSString*exceptionInfo = [NSStringstringWithFormat:@"Exception reason：%@\nException name：%@\nException stack：%@",name, reason, stackArray];
NSLog(@"%@", exceptionInfo);
[UncaughtExceptionHandler saveCrash:exceptionInfo]; //自己实现一个记录下这些信息的方法，作者是实现了一个写文本文件的方法
}
void InstallUncaughtExceptionHandler(void) //注册一些抓取函数，在APPDelegate中didFinishLaunchingWithOptions调用
{
NSSetUncaughtExceptionHandler(&HandleException);
}
2.但NSSetUncaughtExceptionHandler功能非常有限，而引起崩溃的原因如：内存访问错误，重复释放等错误并不能被抓到，而这种错误它抛出的是Signal，因此做一个Signal处理可以抓到这一类的崩溃。
void SignalExceptionHandler(intsignal) //抓取到Signal异常时，执行的方法
{
NSMutableString*mstr = [[NSMutableString alloc] init];
[mstr appendString:@"Stack:\n"];
void* callstack[128];
int i, frames =backtrace(callstack,128);
char** strs =backtrace_symbols(callstack, frames);
for(i =0; i [mstr appendFormat:@"%s\n", strs[i]]; } [SignalHandler saveCrash:mstr]; //同上，自己实现一个记录下这些信息的方法，作者是实现了一个写文本文件的方法 } void InstallSignalHandler(void) //注册抓取函数和抓取的Signal类型，在APPDelegate中didFinishLaunchingWithOptions调用 { signal(SIGHUP,SignalExceptionHandler); signal(SIGINT,SignalExceptionHandler); signal(SIGQUIT,SignalExceptionHandler); signal(SIGABRT,SignalExceptionHandler); signal(SIGILL,SignalExceptionHandler); signal(SIGSEGV,SignalExceptionHandler); signal(SIGFPE,SignalExceptionHandler); signal(SIGBUS,SignalExceptionHandler); signal(SIGPIPE,SignalExceptionHandler); } 3.写完上面两个类，在APPDelegate中didFinishLaunchingWithOptions调用 - (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions { InstallSignalHandler(); InstallUncaughtExceptionHandler(); return YES; } 4.可以写一个demo，按钮函数包含一些崩溃的代码，然后就会发现抓取的崩溃的函数，被执行了，崩溃信息成功输出到了指定的文本文件中。 - (IBAction)buttonClick:(UIButton*)sender { //1.信号量 int list[2]={1,2}; int*p = list; free(p); p[1] =5; } - (IBAction)buttonOCException:(UIButton*)sender{ //2.ios崩溃 NSArray*array=@[@"tom",@"xxx",@"ooo"]; [array objectAtIndex:5]; } 5.得到了关键的堆栈信息，和崩溃原因 到这里，已经知道了，怎么获得到这些信息。下面继续讲一下，怎么根据这些信息，定位到是哪里崩溃的，以及其中可能遇到的一些问题。 从手机直接捞出来的日志，很有可能长这样，一推十六进制的，看不出有效信息。那么问题来了，怎么样转换为看得懂的信息呢？ 符号文件是保存 16 进制函数地址映射信息的中转文件，符号集中存储着文件名、方法名、行号的信息. 符号文件和崩溃日志，具有一一对应的关系。 如何确定符合文件A和崩溃日志B是一一对应的？ 在崩溃日志中会记录一个UUID；用一些工具（比如dwarfdump），可以查询符号文件的UUID；如果是一致的，那就说明这两个文件的一对对应的符号文件和崩溃日志，可以用这个符号文件解析这个崩溃日志。 然后，用dwarfdump、atos等工具，可以将崩溃日志，通过对应的符号文件，将十六进制数通过查符号表，转化为工程中的方法名，代码行号。 比如： 崩溃日志中有一段： 然后，用dwarfdump命令 命令：dwarfdump --uuid Your.app.dSYM 对比两个uuid一致，就对上了。 最后，用symbolicatecrash工具，解析崩溃日志 命令： cd /Users/yourMac/Desktop/崩溃文件夹 symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash 就得到了崩溃日志。 （1）-原始的崩溃文件： 原始的崩溃文件其中一行，拿出来讲解 3 UncaughtExceptionDemo0x00dabe0 0x00d300e + 31698 序号 进程名 崩溃时的堆栈地址 运行时起始地址 + 偏移量 应用崩溃发生时的堆栈地址为0x00dabe0，该进程的运行时起始地址是0x00d300e，崩溃处距离进程起始地址的偏移量为十进制的31698(对应十六进制为0x0007bd2)。 三者对应关系： 0x00dabe0 =0x00d300e+ 0x0007bd2 (崩溃时的堆栈地址= 运行时起始地址 + 偏移量) 接着，去符号表中查询 （2）-获取符号表起始地址 命令：$otool -l Your.app.dSYM/Contents/Resources/DWARF/Your 结果 其中vmaddr = 0x00004000 就是符号表中的起始地址。 符号表崩溃地址 = 符号表起始地址 + 偏移量 = 0x4000 + 0x7bd2 = 0xbbd2 得到符号表中的崩溃地址 （3）-提取.debug_info 命令：$ dwarfdump -e --debug-info YourPath/YourApp.dSYM/Contents/Resources/DWARF > info-e.txt 会生成一个txt，里面包含很多个如下的内容，文件内容举例： 可以知道ViewController::buttonOCException方法的地址范围：0x0000bb76-0x0000bc00。 （4）提取.debug_line 命令：$ dwarfdump -e --debug-line YourPath/YourApp.dSYM/Contents/Resources/DWARF > line-e.txt 会生成一个txt，里面包含很多个如下的内容，文件内容举例： 这里代表的意思是，每一行代码，对应的地址、偏移量。 （5）-结论，得到关键信息： 解析后的崩溃日志为 3UncaughtExceptionDemo-[ViewController buttonOCException:] (ViewController.m:36) 崩溃所在源码文件：/Users/huangchong/iOSCrashUncaught-master/UncaughtExceptionDemo/ViewController.m 发生崩溃的方法：-[ViewController :buttonOCException] 发生崩溃的方法在源文件中的行号：32 崩溃发生的代码行，在源文件中得行号：36
如何读懂、解析日志
1.崩溃日志提供的信息
2.认识符号文件
3.解析的原理
