iOS Crash 崩溃日志总结

iOS 开发中经常遇到各种bug导致崩溃 ，比较常见的例如：数字越界， 空指针， 方法响应错误， 内存问题 等，简单的崩溃还好 ，复杂的崩溃就要借助Crash文件来分析原因，所以在程序崩溃时捕获到异常信息并通知开发者，就非常必要。

---

如何捕获崩溃日志

在iOS中获取崩溃信息的方式有很多，比较常见的是使用友盟、百度等第三方分析工具，或者自己收集崩溃信息并上传公司服务器。下面列举一些我们常用的崩溃分析方式：

使用友盟、百度等第三方崩溃统计工具

现在有很多第三方工具都可以进行崩溃统计分析
友盟崩溃统计官方文档
bugHD统计
这个第三方和友盟的最大区别就是可以直接将崩溃信息分析结合dSYM分析
在bugHD服务器已经帮我们使用dSYM将崩溃符号化完成。我们可以通过点击某条崩溃，查看详细崩溃堆栈，以及崩溃设备分布和系统分布。

Xcode-Devices中直接查看某个设备的崩溃信息

XCode 的菜单Window->Organizer 选择Devices -> 选中的手机 -> 点击手机名称左边的箭头

• 只要手机上的应用是这台电脑安装打包的，这样的崩溃信息系统已经为我们符号化好了，我们只需要进去之后等一会就行(不要相信这里面的进度刷新，并不准确)，如果还是没有符号化完毕 ，我们选择文件，然后右击选择Re-Sysbomlicate就可以 。
• 如果是使用其他电脑进行的打包，我们可以在这里面将Crash文件导出，自己通过命令行的方式进行解析*。）
  

使用苹果提供的Crash崩溃收集服务

• 通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志。
• 苹果自带崩溃统计工具
  苹果在Xcode中为我们集成了崩溃统计功能，在Window->Organizer->Crashes中可以看到
  
  • 苹果自带的崩溃统计工具并不推荐用，如果想要使用这个功能，需要用户在iPhone中进行设置 设置->隐私->诊断与用量->诊断与用量数据(iOS8一下在通用中设置) 选择自动发送，并与开发者共享即可

自己实现应用内崩溃收集，并上传服务器。

在程序启动时加上一个异常捕获监听，用来处理程序崩溃时的回调动作 NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler)
UncaughtExceptionHandler是一个函数指针，该函数需要我们实现，可以取自己想要的名字。当程序发生异常崩溃时，该函数会得到调用，这跟C，C++中的回调函数的概念是一样的。

// 将系统提供的获取崩溃信息函数写在这个方法中，以保证在程序开始运行就具有获取崩溃信息的功能 1. (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {     // 将下面C函数的函数地址当做参数     NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);     return YES;  }  // 设置一个C函数，用来接收崩溃信息  void UncaughtExceptionHandler(NSException *exception){      // 可以通过exception对象获取一些崩溃信息，我们就是通过这些崩溃信息来进行解析的，例如下面的symbols数组就是我们的崩溃堆栈。      //得到当前调用栈信息      NSArray *symbols = [exception callStackSymbols];      //非常重要，就是崩溃的原因      NSString *reason = [exception reason];      //异常类型      NSString *name = [exception name];  }

获取到了崩溃的r日志，如何发送给开发者呢，目前一般有以下两种方式：

1. 将崩溃信息持久化在本地，下次程序启动时，将崩溃信息作为日志发送给开发者。
2. 通过邮件发送给开发者。 不过此种方式需要得到用户的许可，因为iOS不能后台发送短信或者邮件，会弹出发送邮件的界面，只有用户点击了发送才可发送。

// crash infoNSString *crashLogInfo = [NSString stringWithFormat:@"exception type : %@ \n crash reason : %@ \n call stack info : %@", name, reason, arr];// 构建url 发送邮件NSString *urlStr = [NSString stringWithFormat:@"mailto://[e-mail]?subject=bug报告&body=感谢您的配合!错误详情:%@",crashLogInfo];NSURL *url = [NSURL URLWithString:[urlStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];[[UIApplication sharedApplication] openURL:url];

崩溃分析

dSYM 符号集

进行崩溃分析，首先要弄懂一个概念，就是符号集。

• 符号集是我们对ipa文件进行打包之后，和.app文件同级的后缀名为.dSYM的文件，这个文件必须使用Xcode进行打包才有。
• 每一个.dSYM文件都有一个UUID，和.app文件中的UUID对应，代表着是一个应用。而.dSYM文件中每一条崩溃信息也有一个单独的UUID，用来和程序的UUID进行校对。
• 我们如果不使用.dSYM文件获取到的崩溃信息都是不准确的。

• 符号集中存储着文件名、方法名、行号的信息，是和可执行文件的16进制函数地址对应的，通过分析崩溃的.Crash文件可以准确知道具体的崩溃信息。

  我们每次Archive一个包之后，都会随之生成一个dSYM文件。每次发布一个版本，我们都需要备份这个文件，以方便以后的调试。进行崩溃信息符号化的时候，必须使用当前应用打包的电脑所生成的dSYM文件，其他电脑生成的文件可能会导致分析不准确的问题。

  当程序崩溃的时候，我们可以获得到崩溃的错误堆栈，但是这个错误堆栈都是0x开头的16进制地址，需要我们使用Xcode自带的symbolicatecrash工具来将.Crash和.dSYM文件进行符号化，就可以得到详细崩溃的信息。

命令行解析Crash文件

通过Mac自带的命令行工具解析Crash文件需要具备三个文件

• symbolicatecrash，Xcode自带的崩溃分析工具，使用这个工具可以更精确的定位崩溃所在的位置，将0x开头的地址替换为响应的代码和具体行数。
• 我们打包时产生的dSYM文件。
• 崩溃时产生的Crash文件。

在解析崩溃信息的时候，首先在桌面上建立一个Crash文件夹，然后将.Crash、.dSYM、symbolicatecrash放在这个文件夹中，这样进入这个文件夹下，直接一行命令就解决了。

symbolicatecrash我们可以在下面路径下可以找到, 下面是Xcode7路径，其他版本Xcode路径不一样，请自行Google。

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

然后Window->Organizer->Archives中，选中archive的版本右击，选择Show in Finder就可以获取dSYM文件了。

将.Crash、.dSYM、symbolicatecrash三个文件都放在我们在桌面建立的Crash文件夹中。

开启命令行工具，进入崩溃文件夹中
cd /Users/username/Desktop/崩溃文件夹

使用命令解析Crash文件
./symbolicatecrash ./.crash ./.app.dSYM > symbol.crash

如果上面命令不成功，使用命令检查一下环境变量
xcode-select -print-path

返回结果：
/Applications/Xcode.app/Contents/Developer/

如果不是上面的结果，需要使用下面命令设置一下导出的环境变量，然后重复上面解析的操作。
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

解析完成后会生成一个新的.Crash文件，这个文件中就是崩溃详细信息。图中红色标注的部分就是我们代码崩溃的部分。

第三方工具恶意覆盖

崩溃收集统计函数应该只进行一次调用，如果用第三方的话也最好只用一个第三方，这样我们获取崩溃统计信息的途径也是唯一的。

第三方统计工具并不是用的越多越好，使用多个崩溃收集第三方会导致NSSetUncaughtExceptionHandler()函数指针的恶意覆盖，导致有些第三方不能收到崩溃信息。

现在很多第三方崩溃收集工具为了确保自己能最大可能的收集到崩溃信息，会对NSSetUncaughtExceptionHandler()函数指针的恶意覆盖。因为这个函数是将函数地址当做参数传递，所以只要重复调用就会被覆盖，这样就不能保证崩溃收集的稳定性。

http://blog.sina.com.cn/s/blog_b71d24920101ky2d.html
http://blog.csdn.net/jiajiayouba/article/details/44936107
http://www.cocoachina.com/ios/20151218/14748.html