iOS友盟崩溃地址解析 通过dSYM文件分析定位线上 APP crash问题

iOS崩溃定位与dSYM解析
本文介绍如何利用dSYM文件来定位iOS应用的崩溃原因,包括dSYM的作用、获取方式及通过命令行工具解析崩溃地址的具体步骤。

有很多问题是在开发测试过程中无法遇到和重现的,这就需要统计线上的崩溃信息进行定位。

什么是 dSYM

Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下,对于每一个发布版本我们都很有必要保存对应的 Archives 文件

当我们软件 release 模式打包或上线后,不会像我们在 Xcode 中那样直观的看到用崩溃的错误,这个时候我们就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

友盟的崩溃信息跟踪

友盟的使用比较简单,因为崩溃信息中有提示的命令,前提是上线时是你本机的 Xcode 进行的上传或导出工作,因为这样才会有dSYM文件。

首先打开友盟的崩溃统计,找到要定位的 bug,点击绿色的内存地址,就会弹出一个弹框,拷贝弹框中的命令
友盟

然后打开Mac命令行, 将拷贝的命令粘贴进去,按 return 键执行,如果解析成功的话,就会打印出崩溃信息了,方法、文件、行数等。
信息

其他崩溃统计或不是自己打包

如果使用的是其他的崩溃统计服务或者当时并不是自己打包的,只有崩溃信息的内存地址,可以使用下面的办法。

首先,找到当时archive的.xcarchive文件。
如果是本机进行的archive,那么在

/Users/username/Library/Developer/Xcode/Archives

目录下会找到所有的archive文件,该目录是默认的存放目录,如果这是公司的办公本,并且你没有在该目录下找到最近的文件,则有可能是 Xcode 的设置被更改了。
打开 Xcode 首选项,选择最右侧的 locations,就可以看到 Xcode 的相关文件存放路径,点击箭头即可打开文件位置。
archive 文件路径

如果并不是本机进行的 archive,那么找到当时的电脑或则从同事那里拷贝到archive也是可以的。

好的,archive文件已经找到,下面就可以进行定位了。
右键archive文件 选择 显示包内容,然后选择 dSYMs 文件夹里的.dSYM 文件再次显示包内容,然后会找到一个 DWARF 的文件夹,保持该 Finder 窗口打开
archive包内容

dsym

最终路径

第三步,打开终端,先输入 cd,然后选中将DWARF文件夹拖到终端窗口上,会看到 cd 后面自动加上了DWARF文件夹的路径,按 return 键进入该目录下
最后在终端里输入如下命令

atos -arch arm64 -o Xcode 项目名称 内存地址
例如
atos -arch arm64 -o  test-IOS 0x1001cb988

按 return 键执行就会打印出该内存地址的具体文件、方法以及行数等信息,找到崩溃的位置就知道可能的原因以及解决方法了!
文件信息

<think>好的,我现在需要回答用户的问题:当iPhone的“共享iPhone分析”功能关闭时,友盟平台是否仍然能够通过App上传的dSYM文件收集崩溃信息? 首先,我需要理解用户的问题核心。用户想知道在关闭共享iPhone分析的情况下,友盟是否还能利用他们提供的dSYM文件来获取崩溃信息。这可能涉及到友盟的数据收集机制以及dSYM文件的作用。 根据提供的引用内容,dSYM文件主要用于符号化崩溃日志,将内存地址转换为可读的函数名和行号。引用[4]提到,每次编译生成dSYM文件,并且需要保存每个版本的dSYM以便后续分析崩溃日志。而友盟等第三方平台需要用户主动上传dSYM文件才能正确解析崩溃日志,如引用[1]和[2]所说,这些工具通过SDK收集崩溃日志,然后结合dSYM进行符号化。 接下来,我需要分析“共享iPhone分析”功能的作用。这个功能通常是苹果系统级别的数据收集,用于向苹果发送诊断和使用信息。如果用户关闭这个功能,可能影响苹果收集崩溃日志,但第三方工具如友盟是否受影响呢? 根据引用[2],友盟通过自己的SDK在应用崩溃时记录日志并同步到服务器。这意味着崩溃信息的收集是应用内集成的SDK完成的,而不是依赖系统级别的共享分析功能。因此,即使“共享iPhone分析”关闭,只要友盟的SDK正确集成,并且应用在崩溃时触发了SDK的上传机制,友盟应该仍能收集到崩溃日志。不过,这些日志在没有dSYM文件的情况下是难以理解的,所以用户需要上传对应版本的dSYM文件友盟才能解析这些日志,如引用[5]提到的需要UUID匹配。 但要注意的是,如果用户完全关闭了所有分析数据的上传,包括应用内的友盟SDK,那么可能无法收集。但根据常规情况,友盟的数据收集通常不依赖于系统设置,而是应用自身的权限和SDK配置。因此,只要应用内友盟SDK配置正确,且用户没有限制应用本身的网络权限,即使“共享iPhone分析”关闭,友盟仍能收集崩溃信息,并利用上传的dSYM进行解析。 总结一下,关键点在于友盟的数据收集是否独立于系统设置。根据引用内容,是的,因为友盟的SDK在应用层工作,所以关闭系统级共享分析不会影响它。同时,dSYM文件的上传是开发者主动进行的,与用户设置无关,因此友盟仍能使用这些文件解析崩溃日志。</think>当iPhone的“共享iPhone分析”功能关闭时,友盟平台仍然可以通过以下方式获取并解析App崩溃信息: ### 核心结论 1. **友盟通过自身SDK收集崩溃日志** 即使关闭“共享iPhone分析”,友盟SDK会在App运行时主动捕获崩溃事件,并在用户允许网络权限时上传日志到服务器[^2][^3]。这一过程独立于iOS系统级的数据共享设置。 2. **dSYM文件由开发者主动上传** dSYM文件的作用是符号化崩溃日志中的内存地址(如`0x1a3b5c7d`),将其转换为可读的代码位置(如`ViewController.m:32`)[^4][^5]。开发者需手动将编译生成的dSYM文件上传至友盟后台,与用户是否开启“共享iPhone分析”无关[^1]。 3. **必要条件** - App需集成友盟SDK并开启崩溃统计功能。 - 崩溃日志需包含与dSYM文件匹配的UUID(通过`dwarfdump --uuid`命令验证)[^5]。 ### 流程图说明 ``` 用户关闭“共享iPhone分析” → 不影响友盟SDK → SDK捕获崩溃 → 上传原始日志 → 开发者提供dSYM友盟完成符号化 → 显示可读报告 ``` ### 注意事项 - 如果用户禁用App的网络权限,崩溃日志将无法上传至友盟服务器。 - 未正确配置dSYM文件会导致日志无法解析,需确保每个发布版本存档。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值