在iOS开发调试过程当中以及上线以后,程序常常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就须要咱们经过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。web
获取崩溃信息数组
在iOS中获取崩溃信息的方式有不少,比较常见的是使用友盟、百度等第三方分析工具,或者本身收集崩溃信息并上传公司服务器。下面列举一些咱们经常使用的崩溃分析方式:xcode
使用友盟、百度等第三方崩溃统计工具。服务器
本身实现应用内崩溃收集,并上传服务器。app
Xcode-Devices中直接查看某个设备的崩溃信息。函数
使用苹果提供的Crash崩溃收集服务。工具
收集崩溃信息spa
苹果给咱们提供了异常处理的类,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];
}
咱们也能够经过下面方法获取崩溃统计的函数指针:
NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();
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文件
经过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文件了。
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文件导出,本身经过命令行的方式进行解析。
使用第三方崩溃分析工具
如今有不少第三方工具均可以进行崩溃统计分析,使用比较多的是友盟崩溃统计,友盟崩溃统计被集成在友盟SDK中,具体用法直接看官方文档是最好的方法,下面列出友盟崩溃统计文档地址。
在这里我并不推荐友盟这个第三方,而是推荐一个更好用的第三方—bugHD。这个第三方和友盟的最大区别就是能够直接将崩溃信息分析结合dSYM分析好,在web网页上展示出来,并且还能够统计崩溃数、崩溃设备、系统版本等。
下面是我公司使用bugHD统计的一些崩溃状况
bugHD
在bugHD服务器已经帮咱们使用dSYM将崩溃符号化完成。咱们能够经过点击某条崩溃,查看详细崩溃堆栈,以及崩溃设备分布和系统分布。
详细分布
苹果自带崩溃统计工具
苹果在Xcode中为咱们集成了崩溃统计功能,在Window->Organizer->Crashes中能够看到
Crashes
苹果自带的崩溃统计工具并不推荐用,若是想要使用这个功能,须要用户在iPhone中进行设置
设置->隐私->诊断与用量->诊断与用量数据(iOS8如下在通用中设置)
选择自动发送,并与开发者共享便可
第三方工具恶意覆盖
崩溃收集统计函数应该只进行一次调用,若是用第三方的话也最好只用一个第三方,这样咱们获取崩溃统计信息的途径也是惟一的。
第三方统计工具并非用的越多越好,使用多个崩溃收集第三方会致使NSSetUncaughtExceptionHandler()函数指针的恶意覆盖,致使有些第三方不能收到崩溃信息。
如今不少第三方崩溃收集工具为了确保本身能最大可能的收集到崩溃信息,会对NSSetUncaughtExceptionHandler()函数指针的恶意覆盖。由于这个函数是将函数地址当作参数传递,因此只要重复调用就会被覆盖,这样就不能保证崩溃收集的稳定性。
咱们解析崩溃信息时,看到崩溃堆栈只有main.m文件中的崩溃,而且能够肯定不是由于main.m文件中的bug致使的崩溃,就基本能够肯定是NSSetUncaughtExceptionHandler()函数指针被恶意覆盖。