iOS Crash分析

3 Crash 处理

二、用户强制退出

Exception Codes: 0xdeadfa11, deadfall

与正常退出杀死App差异,那种场地可能是用户强制关机或系统强制关机等导致。

一、Watchdog timeout

Exception Code:0x8badf00d

可以读作“eat bad food”,我吃了坏东西,无法持续为您办事了。是否很形象?

当我们的App
在开行、退出、或者在响应系统事件的时候等待了太长期,系统会直接杀死进度。Its
Not A Crash~

大家应有查看App是还是不是在主线程请求了网络,或者其余耗时的事务卡住了健康初阶化流程。

常备系统允许一个App从启动到可以对应用户事件的年月最多为5S,若是跨越了5S,App就会被系统终止掉。在Launch,resume,suspend,quit时都会有照应的时间须求。在Highlight
Thread里面我们得以见见被终止时调用到的岗位,xxxAppDelegate加上行号。

PS.
在连接Xcode调试时为了便于调试,系统会暂时禁用掉沃特chdog,所以此类问题的意识要求使用正规的起步方式。

1 Crash 收集

     
 当程序运行爆发Crash的时候,系统会把运行的最后每一天的程序运行记录封存下去,存储到一个.crash文件中,也就是咱们常说的Crash日志。

一、
 在付出中,最常蒙受的Crash就是Debug状态下了,此时我们是幸运的,因为这些bug大家协调首先精通,大家可以在外人发现它后边把它改好。而且,Xcode
会提须求我们最明确的Crash音讯,直接固定到Crash
的那行代码,并会打印出Crash Reason 及调用栈音讯。

二、借使大家运气稍差点,在开发中自测App没有发现任何Crash问题,但是测试童鞋或者别的机构的童鞋在测试使用中发现了Crash,但愿不要被业主发现o(╯□╰)o。无论此时的crash是必现仍旧非必现,大家都得以得到测试童鞋的Crash设备,获得设备导出Crash日志吧~

三、最愁肠的,无疑是自测没觉察,测试童鞋也没察觉,不过公众的双眼的光亮的,我们亲爱用户碰着了那几个老大难的Crash,那极差的用户体验很有可能让用户粉转黑,怎么做?做一个Crash收集器势在必行!!!~

至于Crash收集的框架,已经有相比早熟的开源框架,KSCrashCrashKit等,也有第三方的Crash计算产品,如CrashlyticsHockeyapp友盟Bugly等等。

引进一篇@念茜的稿子http://nianxi.net/ios/ios-crash-reporter/

       
当App暴发Crash时要上传Crash日志,之后大家能够透过服务端自己的Crash收集器得到Crash文件,或者借助第三方服务获得Crash文件。

三、低内存闪退

当系统发出低内存闪退时,很有可能大家拿不到任何的Crash信息日志,但App的的确确是闪退了。好好做下检讨吧,是否啥地方有内存走漏?用工具好好测试下。

比方大家可以得到日志,会发现它和一般的Crash日志不太一致,经常有Free
pages,Wired Pages,Purgeable pages,largest process
组成,同时会列出当前系统调用栈音讯。

设若我们用的是MRC,首先静态分析一下,是或不是哪儿忘记了release ? dealloc
写的是否正确?
然后使用Instruments检查下内存使用情形,看看什么地方的内存占用较高?是不是内存败露?平日大批量的图纸不可能及时放出内存空间的时候会使内存占用飚升。

内存警告常常在大家debug的时候就会意识,及时的清理掉不用的内存,否则内存占用越来越高,当先系统限制就会被系统杀死。

2 Crash 分析

        得到了Crash日志,大家该从何出手呢?

       
Crash日志会提需要我们不少新闻,大家要在中间领取出来能够帮大家快速定位问题的新闻。

        首先我们看到这几行音讯,

Incident Identifier:崩溃报告的绝无仅有标识符,不一样的Crash日志该标示符也不比。

CrashReporter Key:设备标识相对应的绝无仅有键值(并非真正的装备的UDID,苹果为了维护用户隐衷iOS6未来一度黔驴技穷拿到)。平日同一个配备上等同版本的App发生Crash时,该值都是一律的。

Hardware Model :代表暴发Crash的设施项目。

Process:代表系统Crash的长河名称,常常都是大家的App的名字, [
]个中是即刻过程的ID。

Path:App的四面八方路径。

Identifier:我们App的Indentifier,经常为“com.xxx.yyy”,xxx代表集团的域名,yyy代表某一个App标识。

AppVersion:当前App的本子号,由Info.plist中的多个字段组成,CFBundleShortVersionString and CFBundleVersion。

Code Type:当前App的CPU架构。

Parent Process:当前进程的父进程,由于iOS中App平日都是单进度的,一般父进程都是launchd。

Date/Time:发生crash的时间

Launch Time:启动App的时间

OS Version:iOS系统固件版本

Report Version:日志版本

Exception Type:
这么些音讯格外重大,它就像那么些crash的名字,大家精通了它的名字,解决它还难吗?

Exception
Subtype:它就是crash的小名,当它的芳名满意不断大家的时候,google它的小名,你一定会有收获!~

Triggered by Thread: 问题暴发的thread

咱俩再来看线程音信,在日记中找到crash thread,问题就发出在此地,

稍加情状下,Crashed Thread
的调用栈中会肯定的告知我们是实践到哪些类中哪行代码时暴发了问题,那种情况下大家很简单看清问题由来以及修改问题。不过多数场合下,调用栈里显示我们Crash在了一个连串的库里,我们看不到代码,所以不能规定是啥地方的操作造成了问题,于是,大家必要做点工作,将crash日志文件符号化。

为掌握析crash日志,我们须要七个东西:

1.crash文件

2.符号文件:.dsymb格式

3.应用程序文件:.app格式

接下来大家必要把那两个公文放到同一目录下,用atos命令来符号化crash日志的某一行:

打开终端,输入

xcrun atos -o appName.app/appName -arch armv7

接下来再输入你要符号化的那一行后面的调用栈地址,例如:0x000000018a650b38

如此就可以赢得结果:

就可见稳定到具体是代码的哪一行爆发了问题。

越来越多符号化crash文件的章程,可参看链接。http://wufawei.com/2014/03/symbolicating-ios-crash-logs/

四、Crash due to bugs

因为程序bug导致的Crash平常千奇百怪,很难一面之识。超过半数场地通过Crash日志就足以固定出问题,当然也不免除有些疑难杂症看半天都不足问题出在何方。这些就不得不看功底了,一点点找,总是能觉察马迹蛛丝。是在看不出来时还能求助于谷歌大神,总有人碰着和您同一的Bug

五、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

此类卓殊日常由于线程执行不合规命令导致。

1.在代码中修改了storyboard与outlet的呼应关系,然而storyboard没有更新时发生过此crash。

2.与第三方库中艺术顶牛时暴发过此crash。

3.调用系统方法时传出了不适于的指针类型。

3)EXC_ARITHMETIC

代码中做除法时分母为零了会暴发此问题。

6、Exception Code

0xbaaaaaad此连串型的log意味着该Crash
log并非一个的确的Crash,它仅仅只是包罗了整套体系某一随时的运作状态。平常可以由此并且按Home键和音量键,可能由于用户不小心触发

0xbad22222当VOIP程序在后台太过数次的激活时,系统可能会告一段落此类程序

0x8badf00d其一后面已经介绍了,程序启动或者苏醒时间过长被watch
dog终止

0xc00010ff程序执行大批量消耗CPU和GPU的演算,导致设备过热,触发系统过热珍视被系统终止

0xdead10cc程序退到后台时还占用系统资源,如通信录被系统终止

0xdeadfa11眼前也事关过,程序无响应用户强制关闭

越来越多支出中遇到的错误码可以参见链接https://en.wikipedia.org/wiki/Hexspeak

迎接订阅我的个人主页~

天涯论坛和讯:@小花小叔子是天才

       在iOS开发中,Crash无疑是App的沉重杀手。作为一个行事极为谨慎的iOS
开发人士来说,写出非凡的硬朗的无Crash代码至关主要。但是随着工程代码量的升官,功效的迭代,以及合作开发的情势,难免会有Crash的发生。在暴发Crash时,大家应疾速定位问题,解决问题,将Crash几率降到最低。

相关文章