本文介绍了如何通过crash日志和dSYM文件来定位iOS应用的崩溃问题。首先，找到出问题的线程和崩溃地址，接着从Organizer获取dSYM文件。使用atos命令，结合dSYM和crash信息，可以定位到具体代码行，从而解决崩溃问题。此外，还提到了atos、lldb和dwarfdump等工具在定位crash时的作用。
定位crash最重要的是复现问题，或者获取出现问题的crash文件。
如果根据用户或者测试提供的操作手顺，我们也可以复现问题，那就简单了，直接去device logs中获取crash信息。
如下图：
首先我们找到crash线程，可见Thread 1为出问题线程，然后根据堆栈信息，锁定最上面的一行"0x0000000104a5cc30 0x104484000 + 6130736"为出问题代码。
有了crash的log，接下来需要根据dSYM文件，找到对应代码。至于dSYM文件的作用，大家可以自行百度，解释的非常详细。如果你是负责出版本提交appstore的，一定要注意保存每次提交代码的dSYM文件。
在哪找dSYM呢？
一般在Organizer中，对你Uploaded的版本，点击右键“Show in Finder”，然后对xcarchive文件”显示包内容“。你的dSYM就静静躺在dSYMs目录中
。
理论上在Organizer对版本点击Download Debug Symbols也可以到处，不过我是没成功过，网上有人说是xcode 的bug。
如果你没有生成dSYM文件，也不用慌，打开xcode中的”Build Settings“，找到”Debug Information Format“确保如图：
如果不是手动修改，这里默认就是和图片一样的。
好的，dSYM和crash都齐了，接下来就简单了。
将这两个文件放到一个文件夹中，在终端输入如下命令：
atos -o yourapp.app.dSYM/Contents/Resources/DWARF/yourapp -arch arm64 -l 0x104690000 0x0000000104c68d48
其中0x104690000和0x0000000104c68d48是我们在crash.log获取到的崩溃地址。
输入后输出如下：
结合我的代码，是不是感觉生活如此美好。
除了atos，还有lldb和更高端的dwarfdump也能用来定位crash。这里就不展开了。
扫一扫
2371
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
