前言

作为一个程序开发人员，调试程序编写过程中遇到的各种异常奔溃，是再常见不过的现象了。一般在开发过程中，我们可以通过打断点、输出log等多种方式来调试我们的程序。在iOS开发调试完上线之后，程序仍然会出现崩溃的问题（尽管我们已经尽量做到在上线之前解决遇到的一切问题，但是线上崩溃问题，我们仍然不可避免o(╯□╰)o）。简单的崩溃还好说，但是复杂的奔溃就需要我们通过crash文件来分析了，解析Crash文件在iOS开发过程的不可避免的。由于今天遇到了，自己也查了一些相关资料，做了一些相关了解（原谅本人开发资历尚浅）。这里记录一下，iOS对APP线上Crash现象的调试（主要是Crash信息的收集，然后作出相应的处理）。线下的lldb断点log调试，你们可以查阅这两篇文章
NSLog效率低下的原因及尝试lldb断点打印Log
XCODE LLDB TUTORIAL

获取崩溃信息

这里首先说明一下收集崩溃信息的几种方式

• 自己实现应用内崩溃收集，并上传服务器。
• Xcode-Devices中直接查看某个设备的崩溃信息。
• 使用苹果提供的Crash崩溃收集服务。
• 使用友盟、百度等第三方崩溃统计工具。
  下面就详细说说这四种方式

第一种、自己实现应用内崩溃收集，并上传服务器

苹果给我们提供了异常处理的类，NSException类。这个类可以创建一个异常对象，也可以通过这个类获取一个异常对象。这个类中我们最常用的还是一个获取崩溃信息的C函数，我们可以通过这个函数在程序发生异常的时候收集这个异常，在程序再次启动的时候上传到我们的服务器。这里贴出代码:

// 将系统提供的获取崩溃信息函数写在这个方法中，以保证在程序开始运行就具有获取崩溃信息的功能 
- (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]; 
}

这种自己收集奔溃信息上传自己服务器的方式，是我现在做的项目所采取的方式。优点是：高度自定义，可以上传自己想要的一切信息。但是现在发现一个问题就是收集的信息对于开发人员来说，帮助有限。如图：

Paste_Image.png

• 符号集是我们对ipa文件进行打包之后，和.app文件同级的后缀名为.dSYM的文件，这个文件必须使用Xcode进行打包才有。
• 每一个.dSYM文件都有一个UUID，和.app文件中的UUID对应，代表着是一个应用。而.dSYM文件中每一条崩溃信息也有一个单独的UUID，用来和程序的UUID进行校对。
• 我们如果不使用.dSYM文件获取到的崩溃信息都是不准确的。
• 符号集中存储着文件名、方法名、行号的信息，是和可执行文件的16进制函数地址对应的，通过分析崩溃的.Crash文件可以准确知道具体的崩溃信息。

我们每次Archive一个包之后，都会随之生成一个dSYM文件。每次发布一个版本，我们都需要备份这个文件，以方便以后的调试。进行崩溃信息符号化的时候，必须使用当前应用打包的电脑所生成的dSYM文件，其他电脑生成的文件可能会导致分析不准确的问题。当程序崩溃的时候，我们可以获得到崩溃的错误堆栈，但是这个错误堆栈都是0x开头的16进制地址，需要我们使用Xcode自带的symbolicatecrash工具来将.Crash和.dSYM文件进行符号化，就可以得到详细崩溃的信息。

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

崩溃分析

命令行解析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
如何获取字符集
***第一步：打开 Xcode，选择"Window——>Organizer"

FlAeqMZUGDTcPzVHmx9prx6gxvC3.png

FrkVrxPkRsn3eh9C8ZRNhRSoVx3z.png

FnOHevdMzwjb3oygeIETYmgWjd_l.png

Fn8UzEMe-Zq72lY0JOQ0vE6AzR8t.png

1. 如果建立的项目是用于搜集 Apple Watch 或者 App Extension的崩溃，dSYMs 文件夹下会有多个 dSYM 文件，可以根据 dSYM 文件的尾缀来区分符号表:
   Apple Watch 的 dSYM 文件尾缀是 “AppName WatchKit Extension.appex”
   App Extension 的 dSYM 文件尾缀是“AppExtensionName.appex.dSYM”

2. 如果发现这个位置没有 dSYM 文件，说明你的打包配置设置了打包时不生成符号表。可查看Build Settings -> Build Options -> Debug Information Format 的设置，如果选为DWARF则不会产生dSYM文件，必须选择DWARF with dSYM File才会生成符号表文件。

第五步：Contents/Resources/DWARF 文件夹下的文件即为要上传的符号表

FnrgD8QYEFd4Jpmt4hPyCSAS52Qr.png

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

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

解析完成的结果

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

• 内存访问错误(不是野指针错误)
• 低内存，当程序内存使用过多会造成系统低内存的问题，系统会将程序内存回收
• 因为某种原因触发看门狗机制

第三种、使用苹果提供的Crash崩溃收集服务

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

view device logs

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

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

友盟统计
BugHD
附上几张BugHD 的示例图

Paste_Image.png

Paste_Image.png

Paste_Image.png

本文也是本人学习之互联网，并用作笔记之用。贴出借鉴之出处iOS开发技巧－崩溃调试