有代码的地方，就可能会有崩溃。定位崩溃问题的方法：最直接的，通过重现的步骤去调适；但是，有时候测试无法确定崩溃的步骤，或者崩溃是线上用户发生的，这些情况下，我们仍然可以通过崩溃日志，知道崩溃的原因和崩溃的代码行，从而修复问题。

—— 什么是崩溃？

Application crashes: An applicationtypically crashes when it performs an operation which is not allowed by the operatingsystem.

Server crashes, Operating systemcrashes, …

——定位崩溃原因的方法有哪些？

线索1：重现步骤

线索2：崩溃日志（知道崩溃的原因、崩溃的代码行等信息）

那么，本文就来说说崩溃日志。

●●● 

获取日志的几种方法

在iOS系统中，当应用崩溃的时候，系统会生成一个崩溃日志，保存在设备上。

1.直接在手机上查看

在手机端设置里查看，如图是iOS10的界面：

2.手机连PC用iTunes导出

iTunes同步资料库，然后去PC对应目录下，找文件

Mac OS X:   ~/Library/Logs/CrashReporter/MobileDevice/

Windows XP:   C://Documents andSettings/Application Data/Apple Computer/Logs/Crash/Reporter/MobileDevice

Windows Vista or 7:    C://Users/AppData/Roaming/AppleComputer/Logs/Crash/Reporter/MobileDevice

3.手机连XCode导出

Simulator-Hardware-Device-ManageDevices

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用来做异常处理。

voidHandleException(NSException*exception)   //捕捉到异常时执行的方法

{

//异常的堆栈信息

NSArray*stackArray = [exceptioncallStackSymbols];

//出现异常的原因

NSString*reason = [exception reason];

//异常名称

NSString*name = [exception name];

NSString*exceptionInfo =[NSStringstringWithFormat:@"Exception reason：%@\nException name：%@\nExceptionstack：%@",name, reason, stackArray];

NSLog(@"%@",exceptionInfo);

[UncaughtExceptionHandlersaveCrash:exceptionInfo]; //自己实现一个记录下这些信息的方法，作者是实现了一个写文本文件的方法

}

voidInstallUncaughtExceptionHandler(void)   //注册一些抓取函数，在APPDelegate中didFinishLaunchingWithOptions调用

{

NSSetUncaughtExceptionHandler(&HandleException);

}

2.但NSSetUncaughtExceptionHandler功能非常有限，而引起崩溃的原因如：内存访问错误，重复释放等错误并不能被抓到，而这种错误它抛出的是Signal，因此做一个Signal处理可以抓到这一类的崩溃。

voidSignalExceptionHandler(intsignal) //抓取到Signal异常时，执行的方法

{

NSMutableString*mstr =[[NSMutableString alloc] init];

[mstrappendString:@"Stack:\n"];

void* callstack[128];

inti, frames =backtrace(callstack,128);

char**strs =backtrace_symbols(callstack, frames);

for(i=0; i<frames;++i）{

[mstr appendFormat:@"%s\n", strs[i]];

}

[SignalHandlersaveCrash: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*)applicationdidFinishLaunchingWithOptions:(NSDictionary*)launchOptions {

InstallSignalHandler();

InstallUncaughtExceptionHandler();

returnYES;

}

4.可以写一个demo，按钮函数包含一些崩溃的代码，然后就会发现抓取的崩溃的函数，被执行了，崩溃信息成功输出到了指定的文本文件中。

-(IBAction)buttonClick:(UIButton*)sender {    //1.信号量

intlist[2]={1,2};

int*p= list;

free(p);

p[1]=5;

}

-(IBAction)buttonOCException:(UIButton*)sender{        //2.ios崩溃

NSArray*array=@[@"tom",@"xxx",@"ooo"];

[arrayobjectAtIndex:5];

}

5.得到了关键的堆栈信息，和崩溃原因

到这里，已经知道了，怎么获得到这些信息。下面继续讲一下，怎么根据这些信息，定位到是哪里崩溃的，以及其中可能遇到的一些问题。

●●● 

如何读懂、解析日志

1.崩溃日志提供的信息

从手机直接捞出来的日志，很有可能长这样，一推十六进制的，看不出有效信息。那么问题来了，怎么样转换为看得懂的信息呢？

2.认识符号文件

符号文件是保存 16 进制函数地址映射信息的中转文件，符号集中存储着文件名、方法名、行号的信息.

符号文件和崩溃日志，具有一一对应的关系。

如何确定符合文件A和崩溃日志B是一一对应的？

在崩溃日志中会记录一个UUID；用一些工具（比如dwarfdump），可以查询符号文件的UUID；如果是一致的，那就说明这两个文件的一对对应的符号文件和崩溃日志，可以用这个符号文件解析这个崩溃日志。

然后，用dwarfdump、atos等工具，可以将崩溃日志，通过对应的符号文件，将十六进制数通过查符号表，转化为工程中的方法名，代码行号。

比如：

崩溃日志中有一段：

然后，用dwarfdump命令

命令：dwarfdump --uuidYour.app.dSYM

对比两个uuid一致，就对上了。

最后，用symbolicatecrash工具，解析崩溃日志

命令：

cd /Users/yourMac/Desktop/崩溃文件夹

symbolicatecrash ./*.crash ./*.app.dSYM> symbol.crash

就得到了崩溃日志。

3.解析的原理

（1）-原始的崩溃文件：

原始的崩溃文件其中一行，拿出来讲解

3 UncaughtExceptionDemo0x00dabe0 0x00d300e + 31698

序号 进程名                 崩溃时的堆栈地址    运行时起始地址 + 偏移量

应用崩溃发生时的堆栈地址为0x00dabe0，该进程的运行时起始地址是0x00d300e，崩溃处距离进程起始地址的偏移量为十进制的31698(对应十六进制为0x0007bd2)。

三者对应关系：0x00dabe0 =0x00d300e+ 0x0007bd2

(崩溃时的堆栈地址= 运行时起始地址 + 偏移量)

接着，去符号表中查询

（2）-获取符号表起始地址

命令：$otool -lYour.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-[ViewControllerbuttonOCException:] (ViewController.m:36)

崩溃所在源码文件：/Users/huangchong/iOSCrashUncaught-master/UncaughtExceptionDemo/ViewController.m

发生崩溃的方法：-[ViewController :buttonOCException]

发生崩溃的方法在源文件中的行号：32

崩溃发生的代码行，在源文件中得行号：36

——推荐阅读——

全面复盘！深度剖析直播答题产品架构的难点与坑>>

如何快速设计短信验证码>>

如何做好Android 端音视频测试>>