iOS 崩溃日志解析

一、从 iPhone 等设备中获取崩溃日志并解析 - symbolicatecrash

symbolicatecrash 程序路径(Xcode 9.4.1)：
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

1、Copy symbolicatecrash 程序到 ~/Desktop/CrashAnalyze 目录
2、创建一个工程 CrashDemo，包含会导致崩溃的代码

#import "CustomViewController.h"

@implementation CustomViewController

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    [self generateCrash];
}

- (void)generateCrash
{
    NSArray *array = [NSArray array];
    id obj = [array objectAtIndex:0]; // 这一行崩溃
    NSLog(@"obj -- %@", obj);
}

@end

3、打包并导出 .ipa，安装到 iPhone, 启动 APP 并触发崩溃

exportipa.png

4、打开 Xcode -> Window -> Devices and Simulators -> 选中设备 -> View Device Logs，可以看到设备的所有日志，包括崩溃日志。

crash_report.png

5、将日志导出（选中崩溃日志 -> 鼠标右键 -> Export Log), 保存到和 symbolicatecrash 同一目录 ~/Desktop/CrashAnalyze，后缀名为默认 .crash, 可任意命名,这里命名为 first.crash。

6、copy .dSYM 文件和 .app 文件
打开 Xcode -> Window -> Organizer -> CrashDemo -> Archives -> 刚打的包 -> 右键 -> Show in Finder, 在 .xcarchive 中找到。
这里碰到一个问题：
以前打包的 .xcarchive（具体 Xcode 版本不详），里面只有1个 .dSYM 文件，即名称为“YourAPPName.app.dSYM”，但是 Xcode9.4.1 打包的 .xcarchive，里面有3个 .dYSM文件，

3_dYSM_files.png

另外关于 uuid，.dYSM 文件，.crash 文件和 .app 文件都有 uuid，三者一致时说明是它们是对应的，可以用于符号化解析; 只是这里的 *.app.dSYM 的2个 uuid 与 .crash 文件的 uuid 不一致，另外2个长串名称的其中1个的 uuid 与 .crash 的 uuid 一致，但是用于符号化解析时提示"No symbolic information found", 不能正常解析。

获取 .dYSM 文件 uuid 的方法，输入以下命令

dwarfdump --uuid .dSYM文件名

得到类似以下结果

UUID: 02000565-D5A9-3627-81E5-659B2AC06791 (arm64) 02000565-D5A9-3627-81E5-659B2AC06791.dSYM/Contents/Resources/DWARF/CrashDemo

这里可以看到，与 .app.dSYM 不同的是，这个长串名称的 .dSYM 文件名刚好就是 uuid。

.crash文件的 uuid 可以通过下面的方式找到：
打开 .crash 文件，找到“Binary Images:”行，则这一行的下一行就包含 uuid

crash_uuid_position.png

总结一下目前.xcarchive里的.dsym文件和.app文件的uuid，.crash文件的uuid，导出的.ipa内的.app文件的uuid之间是否一致的情况：

1. .xcarchive 里的 CrashDeme.app.dsym 的 uuid 有2个，与 .xcarchive 里的 .app 的2个 uuid 一致；
2. .xcarchive 里的2个长串名称 .dysm 的 uuid，与导出的 .ipa 内的 .app 文件的2个 uuid 一致，与 .crash 的 uuid 也一致，即3者都一致；
3. 以上1)和2)的 uuid 不一致。

............

现在已找到生成3个 .dSYM 文件的原因：开了 Bitcode. 而如果 Bitcode 是关闭的，就只会产生1个.dSYM, 且它的 uuid 与 .crash 一致。
感谢这篇文章的介绍。
重新导出 .crash 可以看到，崩溃的位置和原因已经被解析出来了

crash_reason.png

按正常方法继续解析崩溃日志：
将 symbolicatecrash，first.crash, CrashDemo.app.dSYM 放到同一个文件夹，执行以下命令

./symbolicatecrash first.crash CrashDemo.app.dSYM > new.crash

这里仍然输出了“No symbolic information found”，new.crash 的内容与 first.crash 完全一致。

虽然最终得到了想要的结果（崩溃原因和位置），但是仍然遗留以下问题：
1.Bitcode 打开时得到的多个 .dSYM 和多个 uuid 的含义和关系，如何对 .crash 进行符号化；
2.Bitcode 关闭，.crash 直接包含崩溃原因和位置，解析时仍出现“No symbolic information found"，原理是什么。

二、第三方工具收集日志和解析 - atos

以百度统计为例, 日志导出如下：

百度统计收集的崩溃日志.png

日志程序崩溃时每个线程的堆栈信息，其中有 Crashed 标识的线程为崩溃所在线程。找到有 APP Name 的行，用后面的地址可解析。
运行如下命令（arm 64）

atos -o yourAPP.app.dSYM/Contents/Resources/DWARF/yourAPP -l 0x1006b4000 0x0000000100d382a8 -arch arm64

其中 0x1006b4000，0x0000000100d382a8 两个地址分别对应崩溃日志中的地址。
输出结果即为符号化的信息，如类名，方法名等。