iOS-----Crash文件分析(一)

开发程序的过程当中无论咱们已经如何当心，老是会在不经意间遇到程序闪退。脑补一下当你在一群人面前自信的拿着你的App作功能预演的时候，流畅的操做被无情地Crash打断。联想起老罗在发布Smartisan OS的时候说了，他准备了10个手机，若是一台有问题，就换一台，若是10台后挂了他就不作手机了。好了不闲扯了，今天就跟你们一块儿聊聊iOSCrash文件的组成以及经常使用的分析工具。

　　有一个WWDC 2010的视频推荐你们抽空看看，视频名称“Understanding Crash Reports on iPhone OS”，该视频详细讲解了Crash文件的结构。固然若是你没时间看的话，不妨阅读如下这篇文章。

 

1、Crash文件结构

当程序运行Crash的时候，系统会把运行的最后时刻的运行信息记录下来，存储到一个文件中，也就是咱们所说的Crash文件。iOS的Crash日志一般由如下6各部分组成。

一、Process Information(进程信息)

Incident Idnetifier	崩溃报告的惟一标识符，不一样的Crash
CrashReporter Key	设备标识相对应的惟一键值(并不是真正的设备的UDID，苹果为了保护用户隐私iOS6之后已经没法获取)。一般同一个设备上同一版本的App发生Crash时，该值都是同样的。
Hardware Model	表明发生Crash的设备类型，上图中的“iPad4,4”表明iPad Air
Process	表明Crash的进程名称，一般都是咱们的App的名字, []里面是当时进程的ID
Path	可执行程序在手机上的存储位置，注意路径时到XXX.app/XXX，XXX.app实际上是做为一个Bundle的，真正的可执行文件实际上是Bundle里面的XXX，感兴趣的能够本身查一下相关资料，有机会我后面也会介绍到
Identifier	你的App的Indentifier，一般为“com.xxx.yyy”，xxx表明大家公司的域名，yyy表明某一个App
Version	当前App的版本号，由Info.plist中的两个字段组成，CFBundleShortVersionString and CFBundleVersion
Code Type	当前App的CPU架构
Parent Process	当前进程的父进程，因为iOS中App一般都是单进程的，通常父进程都是launchd

 

二、Basic Information

Date/Time	Crash发生的时间，可读的字符串
OS Version	系统版本，（）内的数字表明的时Bulid号
Report Version	Crash日志的格式，目前基本上都是104，不一样的version里面包含的字段可能有不一样

 

 

 

三、Exception（很是重要）

Exception Type	异常类型
Exception Subtype:	异常子类型
Crashed Thread	发生异常的线程号

 

 

 

四、Thread Backtrace

发生Crash的线程的Crash调用栈，从上到下分别表明调用顺序，最上面的一个表示抛出异常的位置，依次往下能够看到API的调用顺序。上图的信息代表本次Crash出现xxxViewController的323行，出错的函数调用为orderCountLoadFailed。

五、Thread State

Crash时发生时刻，线程的状态，一般咱们根据Crash栈便可获取到相关信息，这部分通常不用关心。

六、Binary Images

Crash时刻App加载的全部的库，其中第一行是Crash发生时咱们App可执行文件的信息，能够看出为armv7，可执行文件的包得uuid位c0f……cd65，解析Crash的时候dsym文件的uuid必须和这个同样才能完成Crash的符号化解析。

2、常见的Crash类型

一、Watchdog timeout

Exception Code：0x8badf00d， 不太直观，能够读成“eat bad food”，意思是don‘t block main thread

紧接着下面会有一段描述：

Application Specific Information：

com.xxx.yyy　　 failed to resume in time

对于此类Crash，咱们应该去审视本身App初始化时作的事情是否正确，是否在主线程请求了网络，或者其余耗时的事情卡住了正常初始化流程。

一般系统容许一个App从启动到能够相应用户事件的时间最多为5S，若是超过了5S，App就会被系统终止掉。在Launch，resume，suspend，quit时都会有相应的时间要求。在Highlight Thread里面咱们能够看到被终止时调用到的位置，xxxAppDelegate加上行号。 

PS. 在链接Xcode调试时为了便于调试，系统会暂时禁用掉Watchdog，因此此类问题的发现须要使用正常的启动模式。

二、User force-quit

Exception Codes: 0xdeadfa11, deadfall

这个强制退出跟咱们平时所说的kill掉后台任务操做还不太同样，一般在程序bug形成系统没法响应时能够采用长按电源键，当屏幕出现关机确认画面时按下Home键便可关闭当前程序。

三、Low Memory termination

跟通常的Crash结构不太同样，一般有Free pages，Wired Pages，Purgeable pages，largest process 组成，同事会列出当前时刻系统运行全部进程的信息。

关于Memory warning能够参看我以前写的一篇文章IOS 内存警告 Memory warning level。

App在运行过程当中，系统内存紧张时一般会先发警告，同时把后台挂起的程序终止掉，最终若是仍是内存不够的话就会终止掉当前前台的进程。

当接受到内存警告的过后，咱们应该释放尽量多的内存，Crash其实也能够看作是对App的一种保护。

四、Crash due to bugs

由于程序bug致使的Crash一般千奇百怪，很难一律而论。大部分状况经过Crash日志就能够定位出问题，固然也不排除部分疑难杂症看半天都不值问题出在哪儿。这个就只能看功底了，一点点找，老是能发现蛛丝马迹。是在看不出来时还能够求助于Google大神，总有人遇到和你同样的Bug 

3、常见的Exception Type & Exception Code

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

除零错误会抛出此类异常

二、Exception Code

0xbaaaaaad	此种类型的log意味着该Crash log并不是一个真正的Crash，它仅仅只是包含了整个系统某一时刻的运行状态。一般能够经过同时按Home键和音量键，可能因为用户不当心触发
0xbad22222	当VOIP程序在后台太过频繁的激活时，系统可能会终止此类程序
0x8badf00d	这个前面已经介绍了，程序启动或者恢复时间过长被watch dog终止
0xc00010ff	程序执行大量耗费CPU和GPU的运算，致使设备过热，触发系统过热保护被系统终止
0xdead10cc	程序退到后台时还占用系统资源，如通信录被系统终止
0xdeadfa11	前面也提到过，程序无响应用户强制关闭

  

3、获取Crash的途径

一、本机

经过xCode链接测试机器，直接在Device中便可读取到该机器上发生的全部Crash log。

二、itunes connect

经过itunes connect后台获取到用户上报的Crash日志。

三、第三方的Crash收集系统

有不少优秀的第三方Crash收集系统大大的方便了咱们收集Crash，甚至还带了符号化Crash日志的功能。比较经常使用的有Crashlytics，Flurry等。

4、附录

Apple官方文档：Understanding and Analyzing iOS Application Crash Reports

　　　　　　　　Technical Note TN2123 CrashReporter

　　　　　　　　https://developer.apple.com/library/ios/qa/qa1592/_index.html

WWDC视频： 　Understanding Crash Reports on iPhone OS　　　

　　Crash日志记录的时候是将Crash发生时刻，函数的调用栈，以及线程等信息写入文件。通常都是直接写的16进制地址，若是不通过符号化的话，基本上很难获取到有用信息，下一篇咱们将聊一聊Crash日志的符号化，通俗点讲就是让Crash日志变成咱们可读的格式。