iOS 应用 crash 分析

前提

应用崩溃影响用户体验，所以减少iOS应用奔溃是提高应用质量的重要途径。

一、获取iOS应用 crash信息

1,通过itunes同步

1，iOS设备上的应用闪退时, 操作系统会声称一个崩溃日志, 保存在设备上。

路径是:  设置 -> 隐私 ->诊断与用量 ->诊断与用量数据。在这里可以看到设备上所有的设备崩溃日志.
在“诊断与用量”界面，建议用户选择自动发送，这样可以每天自动发送诊断和用量数据到itunes，来帮助开发者分析崩溃.

2，设备与电脑上的ITunes Store同步后, 会将崩溃日志保存在电脑上,崩溃日志保存在以下位置:

Mac OSX :~/Library/Logs/CrashReporter/MobileDevice/ 
可以看到所有和该电脑同步过的设备的崩溃日志(.crash文件)

2，使用Xcode

1，code的Window菜单下的organizer，然后点击Devices tab，然后选中左边的Device Logs。选中某一个崩溃日志，点击Export Log可导出崩溃日志(.crash文件)
2,通过Xcode 获取appStore上架应用的crash信息。

3，其他方式获取部分堆栈信息

1，通过代码获取应用的crash堆栈信息，然后下次启动时上传服务器获得日志信息。
2，通过友盟等第三方SDK拿到应用crash部分堆栈信息。
这种方式获取的应用信息都只有部分堆栈信息

二，获取应用的符号表

1，日志文件

获取日志信息后，需要对堆栈调用信息分析

crash调用堆栈信息如图，有4列：第1列是栈顺序；第2列是二进制包名；第3列是运行地址；第四列是函数的动态加载地址，即加号前面的地址。

2，dSYM文件

在Xcode每次Archives的是都会生成dSYM文件，所有每次打包的时候的都需要保留包文件。点击.xcarchive文件，显示包含内容，在该目录下有生成的dSYM文件。dSYM文件也是Mach-o格式，Mach-O格式全称为Mach Object文件格式的缩写，是mac上可执行文件的格式，类似于windows上的PE格式 (Portable Executable ), Linux上的elf格式 (Executable and Linking Format)。
Mach-O可以分为3个部分

(1)Header
(2)Segment
(3)section
header后面是segment，然后再跟着section，而一个segment是可以包含多个section的。MachOview工具可以可视化查看Mach-O文件格式，我们把dSYM文件放入可视化工具:

该dSYM文件包含armv7和arm64两种架构的符号表。其中arm64的偏移地址时835520

3，UUID

每一个可执行程序都有一个build UUID来唯一标识。Crash日志包含发生crash的这个应用（app）的 build UUID以及crash发生的时候，应用加载的所有库文件的[build UUID]。UUID用来确定二进制包唯一标识

查看日志文件的UUID

localhost:Test guogh$ grep "crashTest arm64" crashTest2017.crash 
0x1000cc000 - 0x1000d3fff crashTest arm64  <87f22ef6f56d3c7fac969d3416cd328a> /var/containers/Bundle/Application/13B84A6F-FB06-484B-8573-9390559A4A71/crashTest.app/crashTest

或者

localhost:Test guogh$ grep --after-context=2 "Binary Images:" crashTest2017.crash 
Binary Images:
0x1000cc000 - 0x1000d3fff crashTest arm64  <87f22ef6f56d3c7fac969d3416cd328a> /var/containers/Bundle/Application/13B84A6F-FB06-484B-8573-9390559A4A71/crashTest.app/crashTest
0x100124000 - 0x100153fff dyld arm64   /usr/lib/dyld

其中 0x1000cc000 就是模块的加载地址。

查看二进制文件的UUID,dSYM文件

localhost:Test guogh$ xcrun dwarfdump --uuid dSYMs/crashTest.app.dSYM/Contents/Resources/DWARF/crashTest 
UUID: 6D16D164-DA42-31C8-8890-94895DB43C47 (armv7) dSYMs/crashTest.app.dSYM/Contents/Resources/DWARF/crashTest
UUID: 87F22EF6-F56D-3C7F-AC96-9D3416CD328A (arm64) dSYMs/crashTest.app.dSYM/Contents/Resources/DWARF/crashTest

或者appName.app／appName文件

localhost:Test guogh$ xcrun dwarfdump --uuid Products/Applications/crashTest.app/crashTest 
UUID: 6D16D164-DA42-31C8-8890-94895DB43C47 (armv7) Products/Applications/crashTest.app/crashTest
UUID: 87F22EF6-F56D-3C7F-AC96-9D3416CD328A (arm64) Products/Applications/crashTest.app/crashTest

需要三者的UUID的匹配才能正确的符号化。即都是：87F22EF6-F56D-3C7F-AC96-9D3416CD328A

三，符号化iOS Crash堆栈

我们拿到的crash信息是堆栈调用信息，所有信息都是16进制的内存地址，不能分析应用crash的原因，需要符号化才能分析。

1，使用Xcode

对于已经上架了appStore的应用的来说，crash文件通过用户上传到苹果服务器，Xcode可以直接下载下来，看到堆栈符号化的堆栈信息就和开发调试一样方便。

2, symbolicatecrash

symbolicatecrash是Xcode带的独立工具，可以拷贝出来使用。查找位置

localhost:~ guogh$ find /Applications/Xcode.app -name symbolicatecrash -type f
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

如果提示Error: "DEVELOPER_DIR" is not defined ,则执行
export DEVELOPER_DIR=/Applications/Xcode.app

把symbolicatecrash和奔溃日志，APP对应的.dSYM文件放在同一文件夹下，执行如下命令：

Symbolicatecrash + 崩溃日志.crash + APP对应的.dSYM文件 + > + 输出到的文件，
或者
Symbolicatecrash + 崩溃日志.crash + appName.app/appName + > + 输出到的文件，
如：
localhost:Test guogh$ ./symbolicatecrash crashTest2017.crash Products/Applications/crashTest.app/crashTest > aa.log

符号化前

Last Exception Backtrace:
0   CoreFoundation                  0x1843391b8 __exceptionPreprocess + 124
1   libobjc.A.dylib                 0x182d7055c objc_exception_throw + 56
2   CoreFoundation                  0x1842147f4 -[__NSArrayI objectAtIndex:] + 184
3   crashTest                       0x1000d0904 0x1000cc000 + 18692
4   crashTest                       0x1000d0864 0x1000cc000 + 18532
5   UIKit                           0x18a1ee924 -[UIViewController loadViewIfRequired] + 1056
6   UIKit                           0x18a1ee4ec -[UIViewController view] + 28
7   UIKit                           0x18a1f4c98 -[UIWindow addRootViewControllerViewIfPossible] + 76
8   UIKit                           0x18a1f2138 -[UIWindow _setHidden:forced:] + 272

symbolicatecrash 符号化后

Last Exception Backtrace:
0   CoreFoundation                  0x1843391b8 __exceptionPreprocess + 124
1   libobjc.A.dylib                 0x182d7055c objc_exception_throw + 56
2   CoreFoundation                  0x1842147f4 -[__NSArrayI objectAtIndex:] + 184
3   crashTest                       0x1000d0904 -[ViewController crashTest] (ViewController.m:29)
4   crashTest                       0x1000d0864 -[ViewController viewDidLoad] (ViewController.m:22)
5   UIKit                           0x18a1ee924 -[UIViewController loadViewIfRequired] + 1056
6   UIKit                           0x18a1ee4ec -[UIViewController view] + 28
7   UIKit                           0x18a1f4c98 -[UIWindow addRootViewControllerViewIfPossible] + 76
8   UIKit                           0x18a1f2138 -[UIWindow _setHidden:forced:] + 272

可以看到第3，4行已经符号化了，显示了哪个文件具体行数，对应代码

查看源码，找出代码crash的原因就容易的多了。但使用symbolicatecrash工具有很大的限制

只能分析官方格式的崩溃日志，需要从具体的设备中导出，获取和操作都不是很方便
符号化的结果也是没有具体的行号信息的，也经常会出现符号化失败的情况。
实际上, Xcode的Organizer内置了symbolicatecrash工具，所以开发者才可以直接看到符号化的崩溃堆栈日志。

3，使用命令行工具atos

命令格式：

 atos -o executable -arch architecture -l loadAddress address

说明：

executable dYSM文件或二进制执行文件appName.app/appName
loadAddress 表示函数的动态加载地址，对应崩溃地址堆栈中 + 号前面的地址，即0x1000cc000
address 表示运行时地址、对应崩溃地址堆栈中第一个地址，即0x1000d0904 ，实际上，崩溃地址堆栈中+号前后的地址相加即是运行时地址，即0x1000cc000 + 18692= 0x1000d0904
执行命令查询地址的符号，可以看到如下结果：

-[ViewController crashTest] (in crashTest) (ViewController.m:29)

四，总结

本文分析了如何获取用户的.crash文件，以及如何符号化的方法，对于分析应用crash很适用。