博客> iOS开发之Crash日志获取与分析
iOS开发之Crash日志获取与分析
2017-06-23 23:57 评论:0 阅读:173 Naruto_yuqin
ios crashLog分析

当在非调试状态下,我们用真机测试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文件。希望这个对大家有所帮助。

收藏
0
sina weixin mail 回到顶部