前言
iOS崩溃是让iOS开发人员比较头痛的事情,app崩溃了,说明代码写的有问题,这时如何快速定位到崩溃的地方很重要。调试阶段是比较容易找到出问题的地方的,但是已经上线的app并分析崩溃报告就比较麻烦了。
之前我总是找到一个改一个,并靠别人测试重现来找出问题的地方,这样往往比较耗费时间。而且比较难找到原因的时候每次都是到网上找各种资源搜索,解决了之后也没有认真分析原因及收集,时间长了之后就会忘记原来解决过的问题,别人来问我的时候我也不能很快找到答案。所以这里写一个关于崩溃的文章,以便之后自己查询用。
这里也会开始写一个demo,争取把所有的崩溃原因都写进demo里。
1.崩溃分析
1.1.崩溃日志(crash log)
1.1.1.xcode中查看崩溃信息
xcode->Window->Organizer->Crashes
![](https://i-blog.csdnimg.cn/blog_migrate/3251febda7b1231550fa8bd740a1f401.webp?x-image-process=image/format,png)
1.1.2.根据符号表来监测奔溃位置
什么是符号表
符号表就是指在Xcode项目编译后,在编译生成的二进制文件.app的同级目录下生成的同名的.dSYM文件。
.dSYM文件其实是一个目录,在子目录中包含了一个16进制的保存函数地址映射信息的中转文件,所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等),所以也称之为调试符号信息文件。
符号表有什么用
符号表就是用来符号化 crash log(崩溃日志)。crash log中有一些方法16进制的内存地址等,通过符号表就能找到对应的能够直观看到的方法名之类。
如何得到.dsYM文件
我们在Archive的时候会生成.xcarchive文件,然后显示包内容就能够在里面找到.dsYM文件和.app文件。
如何使用.dsYM
1.友盟.dsYM分析
如果是使用友盟的话,我们能在错误列表里看到一些错误,然后可以导出奔溃信息,导出的文件为.csv文件。友盟有一个分析工具,使用那个工具可以看到一些错误的函数,行号等。但是很容易分析失败,不知道为什么?
注意:使用的时候要确保你的.xcarchive在 ~/Library/Developer/Xcode/或该路径的子目录下。
.xcarchive里的.dsYM文件和.app文件是有对应的UUID的。然后你的错误详情里也是有UUID,只有当UUID相等时才能分析对。
我犯的错误:因为我们是两个人开发,Archive的时候都是在另一个人的电脑上Archive的,所以我的电脑里根本没有对应的.xcarchive文件。所以我在我电脑上用友盟的分析工具分析是时候是监测不出来错误的。
2.第三方小工具.dsYM分析
或者自己找到.xcarchive文件和错误内存地址(友盟错误详情里标绿色的为错误内存地址)。然后通过一个小应用来分析出对应的函数。应用下载地址,具体可参考文章dSYM 文件分析工具
注意拿来分析的xcarchive名字不要有空格或特殊字符,直接用最简单的数字就好了
下图是我友盟里的错误信息,可以分析的内存地址就是标绿的地方,图中zhefengle就是你的app名,这部分后面的地址就是可以解析符号化的地址:
![]()
下图是分析工具分析上面的错误内存地址:
![]()
分析工具
3.命令行工具symbolicatecrash
symbolicatecrash是xcode的一个符号化crash log的命令行工具。使用方法也就是导出.crash文件(crash log)和找到.dsYM文件,然后进行分析。
4.还有命令行工具atos
如果你有多个“.ipa”文件,多个".dSYMB"文件,你并不太确定到底“dSYM”文件对应哪个".ipa"文件,那么,这个方法就非常适合你。
特别当你的应用发布到多个渠道的时候,你需要对不同渠道的crash文件,写一个自动化的分析脚本的时候,这个方法就极其有用。
简单使用方法命令行工具atos
1.1.3.奔溃日志分析
参考iOS应用崩溃日志分析里面有很详细的分析介绍。
![](https://i-blog.csdnimg.cn/blog_migrate/2859007f5d52cfdeed2976953fa92186.webp?x-image-process=image/format,png)
以上是一个完整的崩溃日志。其实友盟错误详情里的就是上图的第4部分。
如何得到崩溃日志
1.把设备连上电脑,得到自己设备的崩溃日志
崩溃日志可以从xcode里打开Devices看到对应手机的一些奔溃信息。点击下图的View Device Logs就能看到崩溃日志。