iOS开发之Crash日志获取与分析

2017-01-14 10:45:47来源:http://www.jianshu.com/p/531ca1834150作者:naruto_yuqin人点击

第七城市

当在非调试状态下,我们用真机测试app,crash或者说闪退是一件很常见的事,最让我们开发人员头疼的是,自己在开发过程中总是不会遇到crash,安装到别人的设备,就出现了闪退崩溃现象。这种偶现的、概率比较低的闪退是最令人头疼。
这时iOS crash log 派上用场了,程序的大多数crash都会记录在用户的手机中,获取crash log的方法有两种:


用户把设备连接到电脑上,打开xcode-window,选中Devices-当前连接设备-Device Log,就可以查看所有当前设备的crash log,这个时候打开每一份crash的时候,发现这些文件的部分地址都会被转换成,类名,方法名和行号等。设备上的日志只用刚刚查看过都会被同步到organizer种,在LIBRARY下的Device Log可以查看。

如果你的应用已经上架,那么开发者可以通过iTunes Connect(Manage Your Applications - View Details - Crash Reports)获取用户的crash日志。不过这并不是100%有效的,而且大多数开发者并不依赖于此,因为这需要用户设备同意上传相关信息,详情可参见iOS: Providing Apple with diagnostics and usage information摘要。


当上面方法都不行时,就是说在Devices看不到logs时,那就用下面的方法来获取crash日志文件
设备连接iTune,选择设备和mac同步文件,然后保存在手机里的crash日志文件将会同步到电脑,目录在
~/Library/Logs/CrashReporter/MobileDevice/xxx的 iPhone
如下图,就是所有的crash文件:




Paste_Image.png

打开crash日志文件,你会有点蒙圈,因为全都是十六进制的数据



Paste_Image.png



常见的Exception Type & Exception Code
1、Exception Type
1)EXC_BAD_ACCESS
此类型的Excpetion是我们最长碰到的Crash,通常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后面的"()"还会带有补充信息。
SIGSEGV: 通常由于重复释放对象导致,这种类型在切换了ARC以后应该已经很少见到了。
SIGABRT: 收到Abort信号退出,通常Foundation库中的容器为了保护状态正常会做一些检测,例如插入nil到数组中等会遇到此类错误。
SEGV:(Segmentation Violation),代表无效内存地址,比如空指针,未初始化指针,栈溢出等;
SIGBUS:总线错误,与 SIGSEGV 不同的是,SIGSEGV 访问的是无效地址,而 SIGBUS 访问的是有效地址,但总线访问异常(如地址对齐问题)
SIGILL:尝试执行非法的指令,可能不被识别或者没有权限
2)EXC_BAD_INSTRUCTION
此类异常通常由于线程执行非法指令导致
3)EXC_ARITHMETIC
除零错误会抛出此类异常
2、Exception Code
0xbaaaaaad 此种类型的log意味着该Crash log并非一个真正的Crash,它仅仅只是包含了整个系统某一时刻的运行状态。通常可以通过同时按Home键和音量键,可能由于用户不小心触发
0xbad22222当VOIP程序在后台太过频繁的激活时,系统可能会终止此类程序
0x8badf00d这个前面已经介绍了,程序启动或者恢复时间过长被watch dog终止
0xc00010ff程序执行大量耗费CPU和GPU的运算,导致设备过热,触发系统过热保护被系统终止
0xdead10cc程序退到后台时还占用系统资源,如通讯录被系统终止
0xdeadfa11前面也提到过,程序无响应用户强制关闭




其实,crash log里关键的信息就在backtrace,对linux有一定了解的相信对backtrace是有所了解的,其实Linux下常常利用backtrace追踪函数调用堆栈以及定位段错误


那关键的来了,把Backtrace的十六进制数据转成我们能看懂的文字,这个过程我们称之为符号化,那么我们就一步一步讲解


1.上述获取到log后,我们首先找到相对应的.dSYM文件,在哪呢?就在这个目录里: ~/Library/Developer/Xcode/Archives/
2.进入这个目录后,可能会有多个archive文件,找到对应时间的,然后右键显示包内容,可以看到,xxx.app.dSYM文件,如下图:


Paste_Image.png

3.然后再找到上述图片Products/Applications/xxx.app文件
4.将上面crash log文件,xxx.app.dSYM和xxx.app文件拷贝到同一个文件里

怎么确定.dSYM和.app文件是同一个编译出来的呢?
打开终端,使用命令查看两个文件的uuid是否一致,一致则表示.dSYM文件和.app文件是相匹配的,命令如下:
dwarfdump --uuid xxx.app/xxx
dwarfdump --uuid xxx.app.dSYM/ (xxx为app name



5.然后使用命令行工具symbolicatecrash来符号化crash log



怎么找到symbolicatecrash呢?
其实symbolicatecrash工具是Xcode自带的一个命令行工具,找它,当然是去xcode的安装目录咯
先到xcode安装去,一层一层往下走 /Applications/Xcode.app/Contents/SharedFrameworks
这里偷个懒不去找symbolicatecrash在哪个目录了,直接输入查找命令来找find ./ -name "symbolicatecrash",如下图



Paste_Image.png


到这个目录去,把这个工具拷贝到和上述文件同一个目录
sudo cp symbolicatecrash ~/Desktop/xxxxx/xxx



然后就开始符号化,执行命令:
./symbolicatecrash appName-2016-10-26-201420.crash appName.app.dSYM/ > xxxxx.log
(如果执行命令出现错误:Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash,请设置环境变量:export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer;)
打开日志文件,你会发现,backtrace就变成我们可以读懂的代码方法和精准定位到了哪一行了,哈哈




Paste_Image.png


太好用了,这样就遇到偶现的闪退,我们就可以比较轻松的定位问题,最快的定位问题,最好解决问题。


总结

总结一下,整个过程就是,获取crash log -》找到相匹配的 app文件 -》 获取symbolicatecrash工具 -》 符号化crash文件。希望这个对大家有所帮助。




第七城市

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台