iOS从crash信息中查找崩溃原因
之前使用Twitter公司的崩溃搜集工具crashlytics,它可以准确定位APP崩溃的具体原因到代码的某一行。这个工具也被很多的大公司采用。但是因为是Twitter公司的,你们懂得(貌似DNS经常被污染),经常会漏掉很多崩溃信息。对我们的开发非常不利。前几天发现了一款国内 FIR.im公司的产品bughd,因为服务器在国内,crash的反馈速度应该很快,于是我就简单的测试了一下,非常不错。美中不足的是,因为没有上传程序的dSYM文件,所有bughd不能准确定位到崩溃的具体位置。虽然FIR给出了教程(iOS错误堆栈查找崩溃原因的方法),但是可能不是非常浅显易懂,因此我要来个详细的扩展教学!一步步来!
1.制作崩溃代码以及添加bughd SDK
下载bughd SDK,将下载包中的FIR.framework 文件夹拖到Xcode项目中。在应用的设置中, Build Phases -> Link Binary With Libraries里添加SystemConfiguration.framework
在 AppDelegate.m 中:
#import FIR/FIR.h; //导入头文件
然后在application:didFinishLaunchingWithOptions:方法中加入一行:
[FIR handleCrashWithKey:@"YOUR_GENERAL_KEY"];
这里的 YOUR_GENERAL_KEY 是建立每个项目时将自动生成项目对应的General Key。
2.打包程序,并安装到手机上
菜单栏->product->Archive。
如图,在这一步的时候,show in Finder把刚刚生成的最新的xcarchive文件保存一份。
然后打包成功,安装到手机上去(如果是发布,就上传到AppStore上去)
3.查看崩溃信息,并查找原因
当有用户使用此APP崩溃的时候会在bughd后台收到崩溃信息。如图所示:
看这个头都大了吧,下面我教大家解码!
把刚才保存的xcarchive文件打开,显示包内容,将里面的“Products->Applications->文件”和”dSYMs->文件“保存到一个新的文件夹中,这里我的文件夹是CrashReport。
我们来看崩溃信息,具体应该看哪条信息,fir给出了教程已经很清楚了。我们就要序号为3的这种“未标记错误位置,无基地址的情况”
将0x000fdf7f转换为10进制是1040255
1040255-20351 = 1019904
再转为16进制为 0xf9000,这个就是基地址了。
我们打开终端,进入CrashReport文件夹,输入如下命令就可以得到崩溃信息
atos -arch armv7 -o mengmengdai.app/mengmengdai -l 0xf9000 0x000fdf7f
如图所示:
为了证实准确性,我使用了Twitter的crashlytics工具进行了一次崩溃搜集:
注意看序号3,和我们分析出来的崩溃信息一模一样,在这个地方数组越界了!
注意事项:不要两个崩溃搜集同时使用,不然只有一个生效的!
总结:以上是为初学者准备的详细教程,如果有什么不明白,可以再查看FIR.im官方的教程进行进一步理解。
11 评论
谢谢ian对我们的支持 我们的符号表解析功能已经上线了,上传符号表就可以解析到具体的代码行了:)——Sarah-FIR.im
IPHONE 目前还不打算用
@灰常记忆 iphone用的时间久些 起码不会有安卓的UI卡顿
@ian 优缺点都有
偶然經過貴站,盼望回訪xrpmoon(悲劇的新站,日PV不破百……)
@鹏凌三千 亲,贵站的地址不对吧。。。到百度空间了
同楼上,各中高大上。
很高大上的样子啊。
不越狱,坚持不越狱,但是又没什么意思!
就当年iPhone还越狱时,某天突然出现过全机信息尽失的情况……
当时真的心也麻了!
@Betty 我曾经说过为了安全不会越狱,但是我现在就是越狱状态。为了安装shadowsocks
分享您的想法?
撰写评论