iOS崩溃日志分析__dYSM解析
作为一名自认为很牛逼的程序员，当你发现bug时你的内心世界是这样的：
当你定位到bug，并花了一晚上把它改好，发现是同事的问题的时候，你的内心世界可能是这样的：
早上上班时，你压制住内心的愤恨，通过QA并把应用顺利上线时，面对大家的夸奖，你脸上的表情是这样的：
当然，XCode作为一个还算良心的开发工具，他定位bug的方法还是很多的，但是当你的应用已经提交到AppStore后，面对测试过程中无法企及的Crash以及老板看你的眼神
你只能赶紧做到电脑前
最终
然后你看到我这篇文章
在调试过程中，相对于莫名的bug让人难受，其实如果是carsh其实更好捕捉，但是，如果发布到AppStore上线之后崩溃了，其实我们也可以很好的定位到具体的问题，并利用一些手段进行修复。首先我们需要App中接入统计系统，在应用崩溃时记录下崩溃的日志，并且与服务器进行同步，目前百度统计以及友盟应该算是大家用的表较多的第三方工具，按照文档接入对方的SDK后，当上线应用在此碰到崩溃问题时，你就可以查看崩溃日志来定位问题并给他们一个合理的解释。
dYSM文件
当然，分析线上crash你并不需要斋戒沐浴，摆好祭品，大喊太上老君急急如律令，但是你需要打包时生成的.xcarchive的文件包（作为一个良好的习惯，将提审的ipa以及.xcarchive放到服务器，并在git上创建tag会让你在走投无路时看到惊喜）：
.xcarchive文件包
其中AppName就是你的应用的名字。
另外，还需要你统计的carsh记录（我们以百度统计为例），你统计到的崩溃信息大概是这个样子：
崩溃信息
只需要这两样东西，就能准确的定位到app崩溃的具体位置（请不要一脸懵逼的看着我）
准备工作
有了上面提到的.xcarchive文件包以及统计到的崩溃日志，下一步我们需要从崩溃日志中提炼信息：
- 首先UUID: 17FA39D1-CAD6-3212-BF1B-A1325E68F682
-
NAME: AppName：这个是你应用的名字。
注意：只能分析你应用的地址对应的代码块，如图：
可分析的地址
不可以分析系统的代码，因为人家根本就不可能crash
- "CPU Type: arm64"。
- Slide Address: 0x0000000100000000
开始分析
有了上面的信息，我们就可以开始分析了。
-
首先打开终端这个神器的东西，然后用你准备好的xcarchive包右击显示包内容，你会看到一个dSYMs的文件夹：
使用终端到这个目录下：
cd /Users/ys/Desktop/AppName_xcarchive/AppName-3.5.3_20170213_v1_wlan_pro.xcarchive/dSYMs
- 我们可以看到刚才dSYMs文件夹中有一个文件，下面我们需要判断该文件是否于线上app版本UUID相同。
dwarfdump --uuid AppName.app.dSYM
输出结果为：
ysdeMacBook-Pro:dSYMs ys$ dwarfdump --uuid AppName.app.dSYM
UUID: D5113D37-F7D9-32C8-9E28-4C16EE1A0708 (armv7) AppName.app.dSYM/Contents/Resources/DWARF/AppName
UUID: 17FA39D1-CAD6-3212-BF1B-A1325E68F682 (arm64) AppName.app.dSYM/Contents/Resources/DWARF/AppName
我们可以看到这个dSYM的文件的UUID与统计的UUID一致（注意CPU是arm7还是arm64），说明你的包和上线的包是一致的。这样才能够进一步分析。
-
打印错误的详细信息
我们再一次显示AppName.app.dSYM这个文件的包内容：
下面我们可以利用那个AppName的文件来分析崩溃的问题了，在命令行中输入：
xcrun atos -arch arm64 -o /Users/ys/Desktop/AppName-3.5.3_20170213_v1_wlan_pro.xcarchive/dSYMs/AppName.app.dSYM/Contents/Resources/DWARF/AppName -l 0x0000000100000000 0x00000001003b3ec4
或者：
dwarfdump --arch=arm64 --lookup 0x00000001003b3ec4 /Users/ys/Desktop/AppName-3.5.3_20170213_v1_wlan_pro.xcarchive/dSYMs/AppName.app.dSYM/Contents/Resources/DWARF/AppName
输入结果为:
-[ASIHTTPRequest startRequest] (in AppName) (ASIHTTPRequest.m:1196)
或者：
Looking up address: 0x00000001003b3ec4 in .debug_info... found!
0x00523046: Compile Unit: length = 0x000055c9 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00528613)
0x00523051: TAG_compile_unit [110] *
AT_producer( "Apple LLVM version 9.0.0 (clang-900.0.37)" )
AT_language( DW_LANG_ObjC )
AT_name( "/git/JR-Project/JR-iOS/KidReading/KidReading/Lib/ASIHTTPRequest.m" )
AT_stmt_list( 0x00222aba )
AT_comp_dir( "/git/JR-Project/JR-iOS/KidReading" )
AT_APPLE_optimized( 0x01 )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x0000000100535208 )
AT_high_pc( 0x000000010053e29c )
0x00524acd: TAG_subprogram [201] *
AT_low_pc( 0x0000000100537084 )
AT_high_pc( 0x00000001005371bc )
AT_frame_base( reg29 )
AT_object_pointer( {0x00524af6} )
AT_name( "-[ASIHTTPRequest startRequest]" )
AT_decl_file( "/git/JR-Project/JR-iOS/KidReading/KidReading/Lib/ASIHTTPRequest.m" )
AT_decl_line( 544 )
AT_prototyped( 0x01 )
AT_type( {0x0000000000015c7a} ( BOOL ) )
AT_APPLE_optimized( 0x01 )
Line table dir : '/git/JR-Project/JR-iOS/KidReading/KidReading/Data'
Line table file: 'ASIHTTPRequest.m' line 1196, column 19 with start address 0x0000000100537140
Looking up address: 0x00000001003b3ec4 in .debug_frame... not found.
直接便给你定位到文件，行数，以及哪句代码的问题了！
当然也有可能定位不到准确问题，像这样：
pausePlaying:.pauseIndexMp3 (in JoyReader) + 276
或者这样：
Looking up address: 0x000000010073fb30 in .debug_info... not found.
Looking up address: 0x000000010073fb30 in .debug_frame... not found.
解析工具
解析工具 密码：cwnh (github上有很多关于解析工具的代码)
其实在大多数情况下，我们使用解析工具其实来的更快一些，下载解析工具，打开后填入参数，如图：
参数对应填入位置
⚠️arm64 Slide Address默认：0x0000000100000000
⚠️arm7 Slide Address默认：0x00004000
其实这样分析更加显而易见，并且操作简单。其实随着iOS版本不断的迭代，ASI没人维护的问题就更加明显，大家且用且珍惜吧。好了，看完了，可以走了。
