iOS崩溃处理

发表于 | 分类于

[TOC]

前言

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

  • 什么是崩溃？

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对应目录下，找文件

1
2
3
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登录，管理提交的应用，应用细节中有一个崩溃报告

6.app植入第三方sdk，配合第三方平台查看

很多第三方平台，（比如蒲公英、fabric、网易云捕…）提供sdk和管理后台。

只需要使用它们的sdk，并添加几行代码，app运行时，sdk会将应用Crash数据自动上传到后台，后台会进行相应的统计和分析。并给出产品各个版本的崩溃数，崩溃率，影响用户数，崩溃的机型、系统 等。

7.使用苹果的api，自己实现抓取崩溃信息，提交到自己写的后台

和6是一样的，有这些现成的情况下，不是很必要自己重新再写一个，但是可以简单了解一下其中的关键原理。

1.iOS SDK中提供了一个现成的函数NSSetUncaughtExceptionHandler 用来做异常处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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处理可以抓到这一类的崩溃。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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<frames;++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调用

1
2
3
4
5
- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {
    InstallSignalHandler();
    InstallUncaughtExceptionHandler();
    return YES;
}
4.可以写一个demo，按钮函数包含一些崩溃的代码，然后就会发现抓取的崩溃的函数，被执行了，崩溃信息成功输出到了指定的文本文件中。
1
2
3
4
5
6
7
8
9
10
11
- (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.得到了关键的堆栈信息，和崩溃原因

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

如何读懂、解析日志

1.崩溃日志提供的信息

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

2.认识符号文件

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

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

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

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

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

比如：

崩溃日志中有一段：

然后，用dwarfdump命令
命令：

1
dwarfdump --uuid Your.app.dSYM

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

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

命令：

1
2
cd /Users/yourMac/Desktop/崩溃文件夹
symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash

就得到了崩溃日志。

3.解析的原理

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

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

3 UncaughtExceptionDemo0x00dabe0 0x00d300e + 31698

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

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

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

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

接着，去符号表中查询

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

命令：

1
$otool -l Your.app.dSYM/Contents/Resources/DWARF/Your

结果

其中vmaddr = 0x00004000 就是符号表中的起始地址。

符号表崩溃地址 = 符号表起始地址 + 偏移量

= 0x4000 + 0x7bd2

= 0xbbd2

得到符号表中的崩溃地址

（3）-提取.debug_info

命令：

1
$ dwarfdump -e --debug-info YourPath/YourApp.dSYM/Contents/Resources/DWARF > info-e.txt

会生成一个txt，里面包含很多个如下的内容，文件内容举例：

可以知道ViewController::buttonOCException方法的地址范围：0x0000bb76-0x0000bc00。

（4）提取.debug_line

命令：

1
$ 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

------本文结束感谢阅读------