全面的理解和分析iOS的崩溃日志

写在前面:本文会在最开头将苹果官方的文档Understanding and Analyzing Application Crash Reports进行翻译,但这不仅仅是一篇翻译的文章,本文会让大家更加全面的了解ios的崩溃报告的获取、分析、用途。翻译的时候我会结合自己以往的使用经验来进行翻译。

从Xcode获取dSYMs文件

1.下载dsyms文件

在归档管理中选择相应的归档并下载dsyms文件

全面的理解和分析iOS的崩溃日志_第1张图片
1.png
全面的理解和分析iOS的崩溃日志_第2张图片
1.png

2.在归档出的文件中找到dSYMs文件

全面的理解和分析iOS的崩溃日志_第3张图片
1.png
全面的理解和分析iOS的崩溃日志_第4张图片
1.png
全面的理解和分析iOS的崩溃日志_第5张图片
1.png

确定崩溃报告是否被符号化

全面的理解和分析iOS的崩溃日志_第6张图片
1.png

符号化崩溃报告

1.符号化用xcode编译安装软件的设备上的崩溃报告

当应用在设备上运行,遇到崩溃的时候会产生崩溃日志。如果这个应用是用xcode直接在设备上编译运行的,那么就可以将手机连接到编译的时候所用的电脑上,打开xcode,在Window的Devices中去查看日志。找到日志的时候,xcode会自己去符号化崩溃日志。

全面的理解和分析iOS的崩溃日志_第7张图片
1.png

选取设备

全面的理解和分析iOS的崩溃日志_第8张图片
1.png

查看设备日志

[图片上传失败...(image-c0546f-1524877451700)]

xcode自己去符号化崩溃文件

2.符号化用安装包安装在测试设备上的应用所产生的崩溃日志

符号化的时候需要准备symbolicatecrash文件 .dSYM文件 以及.app文件

符号化前先检查一下三者的uuid是不是一致的,只有是一致的才能符号化成功。

查看xx.app文件的uuid的方法:

dwarfdump --uuid xxx.app/xxx (xxx工程名)

查看xx.app.dSYM文件的uuid的方法令:

dwarfdump --uuid xxx.app.dSYM (xxx工程名)

而.crash的uuid位于,crash日志中的Binary Images:中的第一行尖括号内。如:armv7<8bdeaf1a0b233ac199728c2a0ebb4165>

将三种文件拷贝到同一个目录中,在终端中使用命令

./symbolicatecrash ./.crash ./.app.dSYM > xxx.crash来解析崩溃日志。

全面的理解和分析iOS的崩溃日志_第9张图片
1.png

如果想今后解析日志的时候更方便一点,特别是解析多个崩溃日志的时候,如果一个一个去解析的话,很花费时间的。我的话,会将这些写到一个脚本中,解析的时候就只用执行脚本,就可以很方便快捷的获取到崩溃日志。

3.获取并符号化线上的崩溃报告

一.通过打包上线时的xcode来获取线上的崩溃报告

线上app的崩溃日志会被app store收集并符号化分组。类似的崩溃报告的集合被称为崩溃点。(如果用户选择了与苹果共享诊断数据,这些崩溃日志才会被收集并被符号化)

全面的理解和分析iOS的崩溃日志_第10张图片
1.png

在点击相应应用后,会显示此应用的崩溃集合。可以看到每一个集合中都会有很多个设备,如果右键进去查看的话,会看到很多文件。

全面的理解和分析iOS的崩溃日志_第11张图片
1.png
全面的理解和分析iOS的崩溃日志_第12张图片
1.png

再次右键进去查看的话,会最终看到详细的崩溃日志

全面的理解和分析iOS的崩溃日志_第13张图片
1.png

当选中了一个崩溃集合后,如果选择在项目中打开,会在项目代码中找到具体出问题的代码

全面的理解和分析iOS的崩溃日志_第14张图片
1.png
全面的理解和分析iOS的崩溃日志_第15张图片
1.png
全面的理解和分析iOS的崩溃日志_第16张图片
1.png

二、通过友盟等第三方工具来获取崩溃日志

崩溃日志列表

全面的理解和分析iOS的崩溃日志_第17张图片
1.png

其中的一个崩溃日志

全面的理解和分析iOS的崩溃日志_第18张图片
1.png

崩溃的代码的位置,这个是最关键的,可以通过这个来找到代码中的出问题的地方

[图片上传失败...(image-be991a-1524877451700)]

export dSYMPath="$(find ~/Library/Developer/Xcode -iname '*.dSYM' -print0 | xargs -0 dwarfdump -u | grep C0349572-9622-3A00-81D0-4DDE0E00DC7A | sed -E 's/^{FNXX==XXFN}+//' | head -n 1)";是为了找到归档时候产生的dsym文件的路径

dwarfdump --arch=armv7 --lookup 0x426031 "$dSYMPath"是符号化的关键,可以找出出问题的地方。

[图片上传失败...(image-6720a4-1524877451700)]

分析符号化后的崩溃报告

1.头部

每个崩溃报告都会以一个头部开始

其它捕捉和符号化崩溃日志的方法

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
 
    NSSetUncaughtExceptionHandler(&caughtExceptionHandler);
  
    return YES;
}
void caughtExceptionHandler(NSException *exception){
    /**
     *  获取异常崩溃信息
     */
    NSArray *callStack = [exception callStackSymbols];
    NSString *reason = [exception reason];
    NSString *name = [exception name];
    NSString *content = [NSString stringWithFormat:@"========异常错误报告========\\nname:%@\\nreason:\\n%@\\ncallStackSymbols:\\n%@",name,reason,[callStack componentsJoinedByString:@"\\n"]];
    //把异常崩溃信息发送至开发者邮件
    NSMutableString *mailUrl = [NSMutableString string];
    [mailUrl appendString:@"mailto:[email protected]"];
    [mailUrl appendString:@"?subject=程序异常崩溃信息,请配合发送异常报告,谢谢合作!"];
    [mailUrl appendFormat:@"&body=%@", content];
    // 打开地址
    NSString *mailPath = [mailUrl stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:mailPath]];
}

demo地址: https://github.com/zhangxiaomeng1

https://blog.csdn.net/iosfengguibin/article/details/52174822

http://www.cocoachina.com/ios/20171026/20921.html

你可能感兴趣的:(全面的理解和分析iOS的崩溃日志)