iOS中崩溃调试的使用和技巧总结 韩俊强的博客

 每日更新关注:http://weibo.com/hanjunqiang  新浪微博

如今网上有非常多关于解析崩溃信息的博客。可是大多质量參差不齐，或者有些细节没有注意到。今天写一篇博客总结一下我对崩溃调试的使用和技巧，假设有哪些错误或遗漏。还请指点。谢谢。

获取崩溃信息

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

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

• 自己实现应用内崩溃收集，并上传server。

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

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

收集崩溃信息

苹果给我们提供了异常处理的类，NSException类。这个类能够创建一个异常对象，也能够通过这个类获取一个异常对象。

这个类中我们最经常使用的还是一个获取崩溃信息的C函数。我们能够通过这个函数在程序发生异常的时候收集这个异常。

我们也能够通过以下方法获取崩溃统计的函数指针：

dSYM 符号集

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

• 符号集是我们对ipa文件进行打包之后，和.app文件同级的后缀名为.dSYM的文件，这个文件必须使用Xcode进行打包才有。

• 每个.dSYM文件都有一个UUID，和.app文件里的UUID相应，代表着是一个应用。

  而.dSYM文件里每一条崩溃信息也有一个单独的UUID。用来和程序的UUID进行校对。

• 我们假设不使用.dSYM文件获取到的崩溃信息都是不准确的。

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

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

Archive

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

崩溃分析

命令行解析Crash文件

 每日更新关注:http://weibo.com/hanjunqiang  新浪微博

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

• symbolicatecrash，Xcode自带的崩溃分析工具，使用这个工具能够更精确的定位崩溃所在的位置，将0x开头的地址替换为响应的代码和具体行数。

• 我们打包时产生的dSYM文件。

• 崩溃时产生的Crash文件。

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

symbolicatecrash我们能够在以下路径下能够找到，我用的是Xcode7，其它版本号Xcode路径不一样，请自行Google。

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

dSYM文件

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

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文件。这个文件里就是崩溃具体信息。图中红色标注的部分就是我们代码崩溃的部分。

解析完毕的结果

注意，以下情况不会有崩溃信息产生：

• 内存訪问错误(不是野指针错误)

• 低内存，当程序内存使用过多会造成系统低内存的问题，系统会将程序内存回收

• 由于某种原因触发看门狗机制

通过Xcode查看设备崩溃信息

除了上面的系统分析工具来进行分析。假设是我们自己直接使用手机连接崩溃或者崩溃之后连接手机，选择window－> devices －> 选择自己的手机 -> view device logs 就能够查看我们的崩溃信息了。

view device logs

仅仅要手机上的应用是这台电脑安装打包的，这种崩溃信息系统已经为我们符号化好了，我们仅仅须要进去之后等一会即可(不要相信这里面的进度刷新，并不准确)。假设还是没有符号化完毕 ，我们选择文件。然后右击选择Re-Sysbomlicate就能够。

假设是使用其它电脑进行的打包，我们能够在这里面将Crash文件导出，自己通过命令行的方式进行解析。

 每日更新关注:http://weibo.com/hanjunqiang  新浪微博

使用第三方崩溃分析工具

如今有非常多第三方工具都能够进行崩溃统计分析，使用比較多的是友盟崩溃统计。友盟崩溃统计被集成在友盟SDK中，具体使用方法直接看官方文档是最好的方法。以下列出友盟崩溃统计文档地址。

友盟崩溃统计官方文档

在这里我并不推荐友盟这个第三方，而是推荐一个更好用的第三方—bugHD。这个第三方和友盟的最大差别就是能够直接将崩溃信息分析结合dSYM分析好，在web网页上展现出来，并且还能够统计崩溃数、崩溃设备、系统版本号等。

以下是我公司使用bugHD统计的一些崩溃情况

bugHD

在bugHDserver已经帮我们使用dSYM将崩溃符号化完毕。我们能够通过点击某条崩溃，查看具体崩溃堆栈。以及崩溃设备分布和系统分布。

具体分布

苹果自带崩溃统计工具

苹果在Xcode中为我们集成了崩溃统计功能。在Window->Organizer->Crashes中能够看到

Crashes

苹果自带的崩溃统计工具并不推荐用，假设想要使用这个功能。须要用户在iPhone中进行设置

设置->隐私->诊断与用量->诊断与用量数据(iOS8一下在通用中设置)

选择自己主动发送，并与开发人员共享即可

第三方工具恶意覆盖

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

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

如今非常多第三方崩溃收集工具为了确保自己能最大可能的收集到崩溃信息，会对NSSetUncaughtExceptionHandler()函数指针的恶意覆盖。由于这个函数是将函数地址当做參数传递，所以仅仅要反复调用就会被覆盖，这样就不能保证崩溃收集的稳定性。

我们解析崩溃信息时，看到崩溃堆栈仅仅有main.m文件里的崩溃，并且能够确定不是由于main.m文件里的bug导致的崩溃，就基本能够确定是NSSetUncaughtExceptionHandler()函数指针被恶意覆盖。

被恶意覆盖的崩溃堆栈

 每日更新关注:http://weibo.com/hanjunqiang  新浪微博