具有符号性的iPhone应用程序崩溃报告
我正在尝试象征我的iPhone应用程序的崩溃报告。
我从iTunes Connect中检索了崩溃报告。 我有我提交给App Store的应用程序二进制文件，并且具有作为构建一部分生成的dSYM文件。
我将所有这些文件放在一个由聚光灯索引的单个目录中。
现在怎么办？
我曾尝试调用：
symbolicatecrash crashreport.crash myApp.app.dSYM
它只是输出崩溃报告中的相同文本，而不是象征性的。
难道我做错了什么？
分析苹果崩溃报告的步骤：
复制推送到appstore的release .app文件，发布时创建的.dSYM文件和从APPLE接收的崩溃报告到FOLDER中。
OPEN终端应用程序并转到上面创建的文件夹（使用cd命令）
运行atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH 。 内存位置应该是应用程序根据报告崩溃的位置。
例如： atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508
这会显示导致崩溃的确切的行，方法名称。
例如： [classname functionName:]; -510 [classname functionName:]; -510
符号化的IPA
如果我们使用IPA进行符号化 - 只需使用.zip重命名扩展名.ipa，将其解压缩，然后我们就可以得到一个包含应用程序的Payload文件夹。 在这种情况下，我们不需要.dSYM文件。
注意
这只能在应用程序二进制文件没有去除符号的情况下使用。 默认情况下，发布版本剥离了这些符号。 我们可以在项目构建设置“在复制期间去除调试符号”更改为NO。
更多细节请看这篇文章
在阅读所有这些答案后，为了象征一个崩溃日志（并最终成功），我认为这里有一些点是非常重要的，以确定为什么symbolicatecrash的调用不会产生符号输出。
有3个资产必须在符号化崩溃日志时放在一起：
example.crash ），从XCode的管理器导出或从iTunes Connect接收。 .app包（即example.app ）本身包含属于崩溃日志的应用程序二进制文件。 如果你有一个.ipa包（例如example.ipa ），那么你可以通过解压缩.ipa包（例如unzip example.ipa ）来解压.app包。 之后， .app包驻留在解压缩的Payload/文件夹中。 .dSYM包（例如example.app.dSYM ） 在开始符号化之前，您应该检查所有这些工件是否匹配，这意味着崩溃日志属于您拥有的二进制文件，并且调试符号是在该二进制文件的编译期间生成的。
每个二进制文件都由可在崩溃日志文件中看到的UUID引用：
...
Binary Images:
0xe1000 - 0x1f0fff +example armv7 <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff dyld armv7s <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...
在此解压缩中，崩溃日志属于名为example.app/example的应用二进制映像，其UUID为aa5e633efda8346cab92b01320043dc3 。
你可以用dwarfdump检查你的二进制包的UUID：
dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example
之后，您应该检查您的调试符号是否也属于该二进制文件：
dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example
在这个例子中，所有的资产都可以组合在一起，你应该能够象征你的栈跟踪。
进入symbolicatecrash脚本：
在Xcode 8.3中，您应该可以通过调用脚本
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log
如果它不在那里，你可以运行一个find . -name symbolicatecrash find . -name symbolicatecrash在你的Xcode.app目录中找到它的名称以便找到它。
正如你所看到的，没有更多的参数。 所以脚本必须通过运行Spotlight搜索来查找应用程序二进制文件和调试符号。 它使用名为com_apple_xcode_dsym_uuids的特定索引搜索调试符号。 你可以自己做这个搜索：
mdfind 'com_apple_xcode_dsym_uuids = *'
RESP。
mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"
第一个Spotlight调用为您提供了所有索引的dSYM包，第二个为您提供了带有特定UUID的.dSYM包。 如果聚光灯没有找到您的.dSYM包，那么symbolicatecrash将不会。 如果你做了所有这些东西，例如在~/Desktop聚光灯的子文件夹中，应该能够找到所有东西。
如果symbolicatecrash找到您.dSYM包应该有像下面的一行symbolicate.log ：
@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )
为了找到你的.app包，像以下这样的焦点搜索由symbolicatecrash调用：
mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"
如果symbolicatecrash找到您.app包应该有以下摘录symbolicate.log ：
Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH
如果所有这些资源都是通过symbolicatecrash找到的，它应该打印崩溃日志的符号化版本。
如果没有，你可以直接传入你的dSYM和.app文件。
symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log
注意：符号化回溯将输出到终端，而不是symbolicate.log 。
使用最新版本的Xcode（3.2.2），您可以将任何崩溃报告拖放到Xcode Organizer的设备日志部分，它们会自动为您进行符号化。 如果您使用Build＆Archive（也是Xcode 3.2.2的一部分）构建该版本的应用程序，
链接地址: http://www.djcxy.com/p/44963.html