iOS 崩溃日志分析

个人对iOS崩溃日志分析的使用记录。

一、无dsym文件：参考链接： https://www.cnblogs.com/ciml/p/7422872.html#commentform

主要使用了restore-symbol的一个工具，然后3步走：①修改工具restore-symbol权限 ：chmod a+x restore-symbol；② 我们拿到的崩溃日志来自arm64机器，所以先将二进制文件 CrashTest.app/CrashTest 瘦身 （必须正确选择目标CPU架构类型，否则解析出来也是错的，有的包可以跳过这一步）：lipo -thin arm64 CrashTest -output CrashTest-arm64。接着用工具恢复符号表：./restore-symbol -o CrashTest-symbol CrashTest-arm64；③使用苹果自带命令行工具atos，将崩溃地址解析成具体函数：atos -arch arm64 -o CrashTest-symbol -l 0x100030000 0x100034340 0x1000342b0。

# 简单解释一下这个命令，atos -arch CPU架构 -o 进制文件 -l 起始地址 ...一系列内存地址 ； -l 后面跟的是模块的起始地址，再后面可以罗列很多地址，该命令会依次解析出具体函数。最后输出结果类似：-[ViewController getChild:] (inCrashTest-symbol) +64-[ViewController crashOnFunc:] (inCrashTest-symbol) +44。后面有的还会提示具体代码错误行数

注意事项：有这样个场景需要注意，CrashTest.app/CrashTest原代码文件必须与测试手机装的版本一模一样，否则符号化后的函数以及具体地址是不正确的，或者在CrashTest原代码改动小的情况下符号化后的函数以及具体地址是大概正确，但不准确的。那么就有一点需要注意，每个需要测试的版本或是上线的版本，都需要保存其CrashTest文件。为什么说需要注意这点呢，因为其实诸如小公司开发，给测试安装的包是不备份的，上线的有.xcarchive文件，里面可以找到线上的app文件；甚至说这边测试测着，开发的小伙伴（比如我）在那边修改优化一些代码或删除一些文件之类的，造成比如一个V0.1.0，都是build1的版本，但无法完全解析出测试给出的崩溃代码的正确函数及位置。

二、有dsym文件的其实网上资料比较多，这里记录下自己的使用过程：

首先是.crash、xx.app、xx.app.dSYM 3个文件的UUID需要一致（xx.app其实没用到，也可以不看）

1.查看 xx.app 文件的 UUID，terminal 中输入命令 ： dwarfdump --uuid xx.app/xx (xx代表你的项目名)

2.查看 xx.app.dSYM 文件的 UUID ，在 terminal 中输入命令： dwarfdump --uuid xx.app.dSYM

3.查看 xx.crash 文件的 UUID：grep "AppName arm64"  a.crash（而不是原来友盟说的crash 文件第一行）

就是找到Xcode中的symbolicatecrash工具咯，路径为：/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash。

crash文件的分析

①.配置环境变量DEVELOPER_DIR，（配置好了就不再需要）export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

②使用symbolicatecrash工具符号化崩溃日志: ./symbolicatecrash .crash文件 .dsym文件 > xxx.log 

③根据奔溃位置地址信息找到指定位置：dwarfdump--lookup 0x000cf358 --arch armv7 appname.app.dSYM/

好吧，这个流程的3步是个人复制粘贴来的，关键是定位不正确，感觉有点坑，也可能是个人流程错误。所以暂时还是使用无dsym文件的路程方案，之后可能还会来补下这里内容。