Crash文件分析：符号化iOS Crash文件的3种方法
有如下3种方法 方法1 使用XCode 这种方法可能是最容易的方法了。 需要使用Xcode符号化 crash log，你需要下面所列的3个文件： 1. crash报告（.crash文件） 2. 符号文件 (.dsymb文件) 3. 应用程序文件 (appName.app文件，把IPA文件后缀改为zip，然后解压，Payload目录下的appName.app文件), 这里的appName是你的应用程序的名称。 把这3个文件放到同一个目录下，打开Xcode的Window菜单下的organizer，然后点击Devices tab，然后选中左边的Device Logs。 然后把.crash文件拖到Device Logs或者选择下面的import导入.crash文件。 这样你就可以看到crash的详细log了。 如下图
方法2 使用命令行工具symbolicatecrash 有时候Xcode不能够很好的符号化crash文件。我们这里介绍如何通过symbolicatecrash来手动符号化crash log。 在处理之前，请依然将“.app“, “.dSYM”和 ".crash"文件放到同一个目录下。现在打开终端(Terminal)然后输入如下的命令： ? 1 exportDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer 然后输入命令： ? 1 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrashappName.crashappName.app>appName.log 现在，符号化的crash log就保存在appName.log中了。
方法3 使用命令行工具atos 如果你有多个“.ipa”文件，多个".dSYMB"文件，你并不太确定到底“dSYMB”文件对应哪个".ipa"文件，那么，这个方法就非常适合你。 特别当你的应用发布到多个渠道的时候，你需要对不同渠道的crash文件，写一个自动化的分析脚本的时候，这个方法就极其有用。 这里先介绍一个概念： UUID 什么是UUID 每一个可执行程序都有一个build UUID来唯一标识。Crash日志包含发生crash的这个应用（app）的 build UUID以及crash发生的时候，应用加载的所有库文件的[build UUID]。 那如何知道crash文件的UUID呢？ 可以用： ? 1 grep"appNamearmv"*crash 或者 ? 1 grep--after-context=2"BinaryImages:"*crash 可以得到类似如下的结果： ? 1 appName.crash-0x4000-0x9e7fffappNamearmv7<8bdeaf1a0b233ac199728c2a0ebb4165>/var/mobile/Applications/A0F8AB29-35D1-4E6E-84E2-954DE7D21CA1/appName.crash.app/appName （请注意这里的0x4000，是模块的加载地址，后面用atos的时候会用到） 如何找到app的UUID 可以使用命令： ? 1 xcrundwarfdump-–uuid 比如： ? 1 xcrundwarfdump--uuidappName.app/appName 结果如下： ? 1 UUID:8BDEAF1A-0B23-3AC1-9972-8C2A0EBB4165(armv7)appName.app/appNameUUID:5EA16BAC-BB52-3519-B218-342455A52E11(armv7s)appName.app/appName 这个app有2个UUID，表明它是一个fat binnary。 它能利用最新硬件的特性，又能兼容老版本的设备。 对比上面crash文件和app文件的UUID，发现它们是匹配的： ? 1 8BDEAF1A-0B23-3AC1-9972-8C2A0EBB4165 用atos命令来符号化某个特定模块加载地址 命令是： ? 1 atos[-oAppName.app/AppName][-lloadAddress][-archarchitecture] 亲测，下面3种都可以： ? 1 xcrunatos-oappName.app.dSYM/Contents/Resources/DWARF/appName-l0x4000-archarmv7xcrunatos-oappName.app.dSYM/Contents/Resources/DWARF/appName-archarmv7 xcrunatos-oappName.app/appName-archarmv7 （注：这3行选任意一行执行都可以达到目的，其中0x4000是模块的加载地址，从上面的章节可以找到如何得到这个地址。） 文章开头提到crash文件中有如下两行， ? 1 *3appName0x000f462a0x4000+984618*4appName**0x00352aee**0x4000+3468014 在执行了上面的： ? 1 xcrunatos-oappName.app.dSYM/Contents/Resources/DWARF/appName-l0x4000-archarmv7 之后，输入如下地址： ? 1 0x00352aee （crash文件中的第4行：4 appName **0x00352aee** 0x4000 + 3468014） 可以得到结果： ? 1 -[UIScrollView(UITouch)touchesEnded:withEvent:](inappName)(UIScrollView+UITouch.h:26) 这样就找到了应用种到底是哪个模块导致的crash问题。 总结 本文分析了拿到用户的.crash文件之后，如何符合化crash文件的3种方法，分别有其适用场景，方法3适用于自动化crash文件的分析。
