iOS crash 定位方式

iOS crash 定位方式

1. symbolicatecrash 定位

在iOS 中系统提供了开发者对 iOS 系统运行产生的.crash文件进行符号化的工具，也就是symbolicatecrash.

下面我会列举具体的一个操作实践步骤：

1. 在mac 中找到该symbolicatedcrash,可以借助命令行工具进行查找，打开终端执行以下命令：

   find /Applications/Xcode.app -name symbolicatecrash -type f
   

   上面的寻找路径是在Xcode 中进行的，当你安装了多个版本的Xcode 时，可能需要更正上面Xcode.app的具体名称。

   将找到的symbolicatedcrash工具复制一份到你需要进行操作的文件夹.

2. 将需要符号化的.crash 文件和 打包时的dsym文件拷贝到和symbolicatecrash同一目录。

   .crash 文件：

   • 使用Xcode 的 devices and simulate 在连接存在奔溃信息的手机之后，点击View Device Logs

     可以查看手机内部所有App 的crash 文件，找到对应bundleID 具体需要分析时间的crash文件导出

   • 使用手机 设置—>隐私—> 分析-> 分析数据 中对应的crash文件

   dsym 文件：打包时在organizer具体包的 包内容 ->dSYMs路径下的 xxxx.dSYM文件

3. 使用命名将需要符号化的文件 转换

   // 当前目录下的`symbolicatecrash`  需要符号化的crash 符号化文件 > 输出文件
   ./symbolicatecrash xxx.crash xxx.dsym > xxx.text
   

4. 得到可读性的crash 分析文件
   

在使用symblicatecrash 进行符号化时，你可能会遇到符号化话之后 ，意向中二进制文件会变成可读的代码方法模块，但是文件却没有发生任何变化。这个时候你可能需要检查你的符号化文件(dsym) 和 crash文件是否出自同一批次的ipa。

具体的查看方法如下：

dwarfdump --uuid xxx.dsym  

通过上述的命令你会得到当前分析文件 对应 arm64 和armv7等你App 支持的架构类型下的uuid, 使用该uuid 和 crash文件 最末尾的 uuid 进行比较，如果一致，则说明crash 文件和dsym 符号化文件出自同一批次。

2. atos 定位

atos 定位相比较于symblicatecrash 他的一个优点就在于无需 crash文件形式的收集，只需要奔溃时的一个堆栈信息就可以定位（该数据的收集你可以通过日志文件收集等措施获取），下面我列举一下分析步骤：

1. 准备好需要符号化的堆栈信息，计算app 的一个起始地址
   
   App起始地址 = 当前方法的堆栈地址 - 偏移地址

2. 准备好dsym文件
   atos 中使用的文件不同于symblicatecrash，需要的是dsym内部的文件

3. 符号化堆栈信息

atos -o /Users/abe_liu/Desktop/log/场景崩溃/dSYMs/app名称.app.dSYM/Contents/Resources/DWARF/App名称 -l  起始地址 -arch arm64 

4. 直接定位到需要解析的代码方法和具体行数

atos 同样也会遇到相同的问题，他的缺点在于你无法确认使用的dsym 文件和 堆栈信息是否统一。这个就需要开发者在打包时将dsym 文件做好归档。