浅谈iOS Crash（一）

内容简介：iOS Crash问题是iOS开发中难以忽视的存在，本文就捕获iOS Crash、Crash日志组成、Crash日志符号化、异常信息解读、常见的Crash五部分介绍。

一、捕获iOS Crash

1、设置异常断点并运行

说明：设置Xcode异常断点后运行程序，发生Crash时，断点会定位到出错的代码行，但仅适用于开发阶段。线上APP的Crash还需要通过收集Crash机制来捕获Crash并记录在日志中。

2、Mach异常 和 Unix信号

• iOS Crash发生时，先产生Mach异常(最底层的内核级异常)，然后Mach异常在host层被ux_exception转换为相应的Unix信号，并通过threadsignal将信号投递到出错的线程。
• 在捕获Crash事件时，优选Mach异常。因为Mach异常处理会先于Unix信号处理发生，如果Mach异常的handler让程序exit了，那么Unix信号就永远不会到达这个进程了。而转换Unix信号是为了兼容更为流行的POSIX标准(SUS规范)，这样就不必了解Mach内核也可以通过Unix信号的方式来兼容开发。
• 在方案实现时，通过捕获Mach异常+Unix信号组合方式来捕获Crash事件。在选择具体方案时，可以选择PLCrashReporter这样优秀的开源项目，也可以选择友盟、Bugly 这类完善的Crash上报和统计的产品(试项目需求而定)。

3、捕获Crash

并不是所有的Crash都可以捕获到NSException，如果捕获不到，可以使用signal机制来捕获Crash发生时的错误内容。

1) 可以捕获的NSException，通过注册NSUncaughtExceptionHandler捕获异常信息

说明： 使用Objective-C的异常处理是不能得到signal的。

2) 无法捕获的NSException，利用Unix标准的signal机制，注册SIGABRT, SIGBUS, SIGSEGV等信号发生时的处理函数。

二、Crash日志组成

上部分介绍了Crash的捕获，这部分来看看Crash日志的组成。

1、日志内容Demo

日志主要分为六个部分：进程信息、基本信息、异常信息、线程回溯、线程状态和二进制映像。下面是从某APP具体的Crash日志抽出的主要信息，展示如下：

2、日志内容组成分析

整个日志内容中，直接和Crash信息相关，最能帮助开发者定位问题部分是： 异常信息 和 线程回溯部分的内容。

1) 进程信息：发生Crash闪退进程的相关信息

• Hardware Model : 标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。上面的日志里，崩溃日志产生的设备是iPhone 7 Plus (iPhone 7 Plus 也是2个版本 iPhone9,2 和 iPhone9,4. 硬件代号为 D11AP 和 D111AP. 型号有: A1661, A1784, A1785 和 A1786. )
• Process 是应用名称。中括号里面的数字是闪退时应用的进程ID。

2) 基本信息：给出了一些基本信息，包括闪退发生的日期和时间，设备的iOS版本。

3) 异常信息：闪退发生时抛出的异常类型。还能看到异常编码和抛出异常的线程。

• Exception Type异常类型：通常包含1.7中的Signal信号和EXC_BAD_ACCESS，NSRangeException等。
• Exception Codes：异常编码：
• Crashed Thread：发生Crash的线程id

4) 线程回溯：回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单。

5) 线程状态：闪退时寄存器中的值。一般不需要这部分的信息，因为回溯部分的信息已经足够让你找出问题所在。

6) 二进制映像：闪退时已经加载的二进制文件。

三、异常信息解读

1、Exception Type（异常类型）

• Exception Type：通常包含Signal信号 和 EXC_BAD_ACCESS，NSRangeException等。

异常类型	可能的原因	调试方法
EXC_CRASH	unrecognized selector	All Exception Point
EXC_BAD_ACCESS	内存访问错误	NSZombie
SIGSEGV	引用了released对象 / 引用未init的对象 / 数组越界/ 试图往没有写权限的内存地址写数据	NSZombie
SIGABRT	逻辑错误导致的Crash,比如尝试多次释放同一个没存	逻辑检查
SIGPIPE	TCP突然断开，再发送数据	添加signal（SIGPIPE，XX）

具体信号说明参见iOS异常捕获

2、Exception Code（异常编码）

• Exception Code：以一些文字开头，紧接着是一个或多个十六进制值。这些数值说明了Crash发生的本质。
• 从Exception Code中，可以区分出Crash是因为程序错误、非法内存访问还是其他原因。常见的异常编码如下表：

异常编码	描述
0x8badf00d	ate bad food ，表示应用是因为发生watchdog超时而被iOS终止的。通常是应用花费太多时间而无法启动、终止或响应用系统事件。
0xdeadfa11	dead fall，用户强制退出。
0xbaaaaaad	用户按住Home键和音量键，获取当前内存状态，不代表崩溃。
0xbad22222	VoIP 应用因为过于频繁重启而被终止
0xc00010ff	cool off，因为太烫了被干掉
0xdead10cc	dead lock，表明应用因为在后台运行时占用系统资源（如通讯录数据库）
0xbbadbeef	bad beef，发生致命错误

说明1：详细的异常编码代表的含义请参考：Hexspeak

说明2：在后台任务列表中关闭已挂起的应用不会产生崩溃日志。 因为应用一旦被挂起，它何时被终止都是合理的。所以不会产生崩溃日志。

四、Crash日志符号化

1、概述

线程回溯部分内容如下：

这两条记录包括四列:（以第一条记录为例子）

• 帧编号—— 5（数字越小，发生时间越晚，发生顺序越往后，越好锁定问题的范围）
• 二进制库的名称 ——此处是 AppName.
• 调用方法的地址 ——此处是 0x0000000100205280.
• 第四列分为两个子列，一个基本地址和一个偏移量。此处是 x0000000100028000 + 1954432, 第一个数字指向文件，第二个数字指向文件中的代码行。

说明1：线程回溯部分并不是我们习惯使用方法名和行数，而是十六进制地址。所以我们在分析Crash前需要将这些十六进制地址转化成方法名称和行数，改过程被称为符号化。

说明2：符号化Crash日志需要获取对应的应用二进制文件以及生成二进制文件时产生的 .dSYM 文件（符号表）。必需完全匹配才行。否则，日志将无法被完全符号化。

说明3： Xcode编译项目后，会得到同名的 dSYM 文件（符号表），dSYM 文件（符号表）是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users//Library/Developer/Xcode/Archives 目录下，对于每一个发布版本我们都很有必要保存对应的 Archives 文件。

说明4：符号化可以使用Xcode的两种命令 symbolicatecrash命令 + atos命令

2、symbolicatecrash命令

1）首选找到symbolicatecrash命令的位置

2）找到线上版本对应的xcarchive文件。从中找到.dSYM和.app文件

3）获取crash日志文件

• 线上App的Crash日志经由Crash日志收集服务获得(主要来源)。
• 也可以从真机上获取Crash日志文件。点击Window -> Devices，选择你自己的机器，然后点击View Device Logs，右键可以导出Crash文件。
• 获取的这些日志文件都需要符号化处理。

4）将symbolicatecrash、.dSYM、.app、crash.crash拷贝到桌面下同一个文件夹下

5）检查 xx.app 和 xx.app.dSYM 文件以及crash 文件这三种的 UUID是否一致。

• 查看 xx.app 文件的 UUID，terminal 中输入命令 ：
  
  Objective-C

  dwarfdump --uuid xx.app/xx (xx代表你的项目名)

  1	dwarfdump --uuid xx.app/xx (xx代表你的项目名)

• 查看 xx.app.dSYM 文件的 UUID ，在 terminal 中输入命令：
  
  Objective-C

  dwarfdump --uuid xx.app.dSYM

  1	dwarfdump --uuid xx.app.dSYM

• 查看crash 日志中的Incident Identifier （crash 文件的 UUID）

6）使用命令，生成“可定位问题的crash文件”

7） 根据符号化后的线程回溯信息，可以帮助定位出问题的代码行。

说明：如果执行symbolicatecrash命令出现 Error: “DEVELOPER_DIR” is not defined at ./symbolicatecrash…这样的错误，可以在执行命令前，输入export DEVELOPER_DIR=”/Applications/XCode.app/Contents/Developer”

3、atos命令

在符号化时候，还可以使用atos命令。发现armv7处理器上的crash使用symbolicatecrash无法符号化。

1）将.dSYM、.app、crash.crash放到同一个文件夹下。

2） 知道crash文件的UUID：执行grep “AppName arm” *crash，得到结果

其中0x100040000、0x100060000、0x5000是加载地址(loadingAddress), 而arm64、armv7 是 architecture 的值(architectureValue)，这两个值后面都要用。

3）然后执行atos命令,输入成功，进入待输入状态

4） 此时输入App对应的Crash地址，得到发生crash的信息。

实例1：

实例2：

五、常见的Crash

有一些Crash比较常见，下面罗列出5种常见的Crash。

1、数组操作

• 场景1：取数据索引越界。一般发生在UITableView的使用中，因为cellForRowAtIndexPath代理方法是异步执行的，UITableView对象的dataSource一旦在加载数据过程中发生变化，极有可能发生数组越界的异常。在多线程场景下，列表界面的数据有可能经常变化，很可能发生；当列表界面数据不怎么变化的时候，几乎感知不到这种异常的存在。解决办法：从数组中取数据前，校验索引是否正确。
  
  Objective-C

  @implementation NSMutableArray (Safe) - (id)safeObjectAtIndex:(NSUInteger)index{ if (index < self.count){ return [self objectAtIndex:index]; }else{ NSLog(@"警告:数组越界!!!"); } return nil; } @end

  1 2 3 4 5 6 7 8 9 10 11 12 13

  @implementation NSMutableArray (Safe)   - (id)safeObjectAtIndex:(NSUInteger)index{        if (index < self.count){          return [self objectAtIndex:index];      }else{          NSLog(@"警告:数组越界!!!");      }          return nil; }   @end

• 场景2：数组添加数据对象时nil解决办法：添加对象到数组前，判断是否是nil

说明：数组的删除等操作处理类似，数组操作前要进行数据校验。

2、多线程下的Crash

• 一般多线程发生的Crash，会收到SIGSEGV信号，表明试图访问未分配给自己的内存, 或试图往没有写权限的内存地址写数据。
  • 场景1：子线程中更新UI

  解决办法：将UI更新操作放在主线程中，可以使用performSelectorOnMainThread 或 GCD

  Objective-C

  //子线程中，使用宏将更新UI的任务派发到主队列 #define dispatch_main_sync_safe(block) \ if ([NSThread isMainThread]) { \ block(); \ } else { \ dispatch_sync(dispatch_get_main_queue(), block); \ } #define dispatch_async_main(block) dispatch_async(dispatch_get_main_queue(), block)

  1 2 3 4 5 6 7 8 9

  //子线程中，使用宏将更新UI的任务派发到主队列   #define dispatch_main_sync_safe(block) \   if ([NSThread isMainThread]) { \      block(); \   } else { \       dispatch_sync(dispatch_get_main_queue(), block); \   }     #define dispatch_async_main(block)              dispatch_async(dispatch_get_main_queue(), block)

• 场景2：多线程中创建单例解决办法：使用dispatch_once，保证代码只执行一次，保证线程安全。
  Objective-C

  //以QSAccountManager单例为例 static QSAccountManager *_shareManager = nil; + (instancetype)shareManager{ static dispatch_once_t once; dispatch_once(&once, ^{ _shareManager = [[self alloc] init]; }); return _shareManager; } + (instancetype)allocWithZone:(struct _NSZone *)zone{ static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _shareManager = [super allocWithZone:zone]; }); return _shareManager; } - (nonnull id)copyWithZone:(nullable NSZone *)zone{ return _shareManager; }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  //以QSAccountManager单例为例   static QSAccountManager *_shareManager = nil;   + (instancetype)shareManager{         static dispatch_once_t once;       dispatch_once(&once, ^{           _shareManager = [[self alloc] init];       });       return _shareManager;   }     + (instancetype)allocWithZone:(struct _NSZone *)zone{         static dispatch_once_t onceToken;       dispatch_once(&onceToken, ^{           _shareManager = [super allocWithZone:zone];       });       return _shareManager;   }   - (nonnull id)copyWithZone:(nullable NSZone *)zone{       return _shareManager;   }

• 场景3：多线程下非线程安全类的使用，如NSMutableArray、NSMutableDictionary解决办法：使用派发队列或锁保证数据读写安全。具体实现详见 iOS实录12：NSMutableArray使用中忽视的问题中第一部分。
• 场景4：数据缓存到磁盘和读取。解决办法：使用派发队列或锁保证数据读写安全。如将数据的读取和写异步放入串行同步队列，保证数据同步，线程安全。

3、WatchDog 超时造成的Crash

• 一般异常编码是0x8badf00d ，表示应用是因为发生watchdog超时而被iOS终止的。通常是应用花费太多时间而无法启动、终止或响应用系统事件。
• 场景1：主线程中执行耗时的操作，导致主线程被卡超过一定的时间。解决办法：主线程中只负责UI的更新和响应，将耗时的操作采用异步的方式放到后台线程执行。耗时操作包括：网络请求，数据库读写等。

4、performSelector:withObject:afterDelay下的Crash

• 场景1：对象释放比performSelector:afterDelay要早解决办法：在对应类的dealloc中执行cancelPreviousPerformRequestsWithTarget取消执行。

5、SIGPIPE导致的程序退出

• 当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。而根据信号的默认处理规则，SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。
• 场景：长连接socket或重定向管道进入后台，没有关闭解决办法1：切换到后台时，关闭长连接和管道，回到前台再重建；解决办法2：使用signal(SIGPIPE,SIG_IGN)，将SIGPIPE交给了系统处理。这么做将SIGPIPE设为SIG_IGN，使得客户端不执行默认动作，即不退出。

End

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 浅谈iOS Crash（一）

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。