Soo，随着TestFlight的结束，能够完全理解iOS崩溃日志变得更加紧迫。
此处有关于此主题的众多问题，但根据我的经验，这些解决方案都没有提供对崩溃本身的充分了解。 在iOS世界中，似乎仍然存在相当混乱。
为了完成，这里是我发现和采取的方法和步骤。
（Disclamer：我可以访问所有内容：.app文件，.dSYM和.crash文件）
1 | symbolicatecrash - 命令行实用程序
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer” sudo cp /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash /usr/bin dSYM file, the .app file and the .crash file放入相同文件夹 symbolicatecrash “FILENAME.crash" "FILENAME.app" "FILENAME.app.dSYM" 2 | atos - 命令行实用程序
8 NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625 atos -arch armv7 -o NAME_OF_MY_APP.app/NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625 第3 | GDB
<小时/> 现在要么我愚蠢，要么愚蠢，要么两者兼而有之，但对我而言，所有这些方法的问题在于它们不一致。
根据我的经验，使用symbolicatecrash进行符号化会为所有堆栈跟踪提供方法名称，但没有行号和很少没有关于抛出异常的信息。
Atos更具描述性，但仍然没有异常描述，您必须为所有想要符号化的行手动执行此操作。
此外，atos有时会指向不在symbolicatecrash的输出中的方法调用...
当我将一个构建版本与.dSYM一起上传到TestFlight时，他们可以为我提供我在这些符号中找不到的精确方法名称，行号和异常描述。
<小时/> 即使在崩溃日志中也是例外说明吗？
我们是否必须在应用中实施未处理的异常处理程序，并将报告“回家”（即发送到 Web服务器？）才能访问抛出了什么异常，在哪里？
答案 0 :(得分：2)
symbolicatecrash - 命令行实用程序
您正在调用脚本错误，它应该是：
symbolciatedcrash “FILENAME.crash" "FILENAME.app.dSYM"
atos - 命令行实用程序
这个电话也错了：
atos -arch armv7 -l LOAD_ADDRESS_OF_THE_APP -o NAME_OF_MY_APP.app.dSYM 0x000ad031
LOAD_ADDRESS_OF_THE_APP是您应用的Binary Images部分中显示的第一个地址。另见：iOS crash reports: atos not working as expected
现在关于其他问题/评论：
使用symbolicatecrash无法显示行号：
这是因为您传递了应用程序二进制文件，它主要删除了所有符号（由于大小），即使符号不会被剥离，也不会显示行号。如果有，请务必使用dSYM进行符号化。
缺少例外说明：
在大多数情况下，Apple的iOS崩溃报告不会在包含该信息的报告中提供Application Specific Information块。如果您只有苹果崩溃报告，那么您无能为力
其他一些信息：
符号系统调用
您需要使用特定CPU架构和iOS版本的符号创建崩溃报告。因此，您至少需要一个具有特定iOS版本的armv7设备和arm64设备，并且至少有一次连接到Xcode，它可以导入符号。否则，报告中会出现未符合标准的符号。
让Xcode象征它
如果您的系统设置正确，您只需将崩溃报告拖到Xcode管理器的顶部Devices Logs条目中，它就会为您调用symbolicatecrash并通过Spotlight找到正确的dSYM。 （需要聚光灯索引dSYMs文件夹）
收集崩溃报告的替代方法
有多种替代方案可用于收集崩溃报告。开源解决方案，免费服务和付费服务，提供SDK以收集应用中的崩溃报告并将其发送到服务器，进行符号化并自动分组。 （免责声明：我是QuincyKit开源项目的开发者和HockeyApp.net服务的联合创始人）