iOS Crash

iOS崩溃问题一直是令开发人员痛苦的事情，那么如何高效的定位崩溃问题并有效的解决呢？下面所讲解的一些方式，都能够有效解决崩溃问题。当前归类三种情况，开发人员开发崩溃，测试内测崩溃，使用者线上崩溃。

开发崩溃定位

1.当前xcode处于开发模式的时候，使用僵尸调测或者使用LLDB,GDB命令调测，打印崩溃信息，具体选择如下图，选择LLDB调测模式（属于xcode当前自带的内容），如果要选择GDB调测模式，需要下载相关GDB 相关的插件，根据崩溃内存地址内容，使用LLDB,GDB命令可以轻松定位相关的信息，在edit scheme中同时需要勾选Diagnostics的Run中Objective-c (Enable Zombie Objects，Malloc Stack)中显示内存地址。

2.使用全局断点检测当前xcode运行出现的崩溃信息，对于当前的崩溃位置断点会自动定位。对于没有成功定位的时候，可以结合方式1定位相关的bug

3.如果是Xcode7以上，在edit sheme中需要够炫Diagnostics的Run选项中的Runtime Sanitization的Enable Address Sanitizer，出现崩溃将会自动定位。

4.message sent to deallocated instance 0x6d564f0类似的这种崩溃问题，可以通过LLDB的命令(bt或者info malloc-history 0x6d564f0）定为道崩溃信息。当然我们也可以通过打开”活动监视器”找到对应的PID(进程ID)和当前的崩溃地址在终端输入,可以定为到详细的当前崩溃对象的完整的生命周期。

sudo malloc_history 50127 0x6d564f0

内测崩溃定位

1.内测版本具体的某一个设备崩溃了，可以将该设备交与开发人员，开发人员通过xcode到处设备中的crash崩溃信息，即可查看崩溃信息，分析后定为

2.内测版本中也可通过集成第三方的崩溃捕捉工具进行

• fir的BugHD平台CI过程上传ipa同时上传每个版本的dsym文件
• 也可以可以通过Crashlytics,友盟这些第三方的平台进行（友盟不可以上传dsym）
• Bugtags,超级强大的bug管理系统，方便测试人员提交bug并且高效的管理，可以直接使用手机操作提交bug，但是这个是要收费的。

线上崩溃定位

1.对于需要发布的项目，可以事先在程序中将如(Crashlytics,友盟等第三方崩溃定位的文件，也可以使用QuincyKit结合PHP服务端搭建自己的bug系统管理后台），根据archive文件（也就是十六进制文件，发包前的编译文件后的内存地址，实际第三方地位到的内存地址就是这个）定位第三方服务端提供的崩溃信息（内存地址）。如下图友盟定位的崩溃信息日志，
对于这样的一个崩溃信息，大多数人措手不及，但是通过dsym文件（十六进制内存地址），根据提示信息

3   LR                                  0x10c527 LR + 1082663
21  LR                                  0xf258b LR + 976267

根据之前发包的archive文件，（关于怎么找到archive文件，Command + shift +2）
找到对应时间的archive文件后，选择鼠标右键find show archive文件后，找到文件后，选择显示包含的内容知道DAWF文件后具体的路径显示简介即可找到/Users/qianjx_tyrbl/Library/Developer/Xcode/Archives/2014-08-12/4.30.xcarchive/dSYMs/LR.app.dSYM/Contents/Resources/DWARF，进入DWARF文件，在terminate终端输入

dwarfdump --uuid LR //查看当前项目的uuid（LR表示项目名称），是否和第三方定位的崩溃匹配uuid
atos -arch armv7 -o LR 0x10c527 //armv7内存地址对应的内容
atos -arch arm64 -o LR 0x10c527 //arm64内存地址对应的内容

2.当然如果你是用电脑archive的方式，在上传appstore的时候，苹果会有提示是否勾选上传dsym文件，那么在本台机器上面即可查到对应提交版本所有线上崩溃的问题。