iOS CrashLog分析详细分析了iOS崩溃日志的非代码层面的收集和解析。这篇文章分析一下如何用纯代码来收集分析程序崩溃。
问题一：平时程序遇到崩溃的本质？
引发崩溃的代码本质上就两类：
1.一个是c++语言层面的错误，比如野指针，除零，内存访问异常等等。无论是iOS还是android系统，其底层都是unix或者是类unix系统,都可以通过信号机制来获取 signal或者是sigaction.设置一个回调函数.
2.另一类是未捕获异常（Uncaught Exception），iOS下面最常见的就是objective-c的NSException（通过@throw抛出，比如，NSArray访问元素越界），android下面就是java抛出的异常了。这些异常如果没有在最上层try住，那么程序就崩溃了.可以使用NSUncaughtExceptionHandler来进行抓取。这种取到的日志是已经符号化过后的。
使用NSUncaughtExceptionHandler抓取NSException
NSSetUncaughtExceptionHandler(&ExceptionHandler);
void ExceptionHandler(NSException *exception)
{
//NSString *reason = [exception reason];
//NSString *name = [exception name];
NSLog(@"%@",exception.userInfo);
NSString* ret=[NSString stringWithFormat:@"异常名称:\n%@\n\n异常原因:\n%@\n\n出错堆栈内容:\n%@\n",name,reason,[exception callStackSymbols] ];
NSLog(@"%@",ret);
}
抓取Signal消息
signal信号是Unix系统中的,是一种异步通知机制.信号传递给进程后,在没有处理函数的情况下,程序可以指定三种行为,
- 忽略该信号,但是对于信号SIGKILL和SIGSTOP不可忽略
- 使用默认的处理函数SIG_DFL,大多数信号的默认动作是终止进程.
捕获信号,执行用户定义的函数. - 有两个特殊的常量:
SIG_IGN,向内核表示忽略此信号.对于不能忽略的两个信号SIGKILL和SIGSTOP,调用时会报错.
SIG_DFL,执行该信号的系统默认动作.
还有两个常用的函数
int kill(pid_t pid, int signo); //发送信号到指定的进程
int raise(int signo); //发送信号给自己.
UNIX系统中常用的信号有
SIGABRT--程序中止命令中止信号
SIGALRM--程序超时信号
SIGFPE--程序浮点异常信号
SIGILL--程序非法指令信号
SIGHUP--程序终端中止信号
SIGINT--程序键盘中断信号
SIGKILL--程序结束接收中止信号
SIGTERM--程序kill中止信号
SIGSTOP--程序键盘中止信号
SIGSEGV--程序无效内存中止信号
SIGBUS--程序内存字节未对齐中止信号
SIGPIPE--程序Socket发送失败中止信号
抓取Signal的代码
signal(SIGHUP, SignalExceptionHandler);
signal(SIGINT, SignalExceptionHandler);
signal(SIGQUIT, SignalExceptionHandler);
signal(SIGABRT, SignalExceptionHandler);
signal(SIGILL, SignalExceptionHandler);
signal(SIGSEGV, SignalExceptionHandler);
signal(SIGFPE, SignalExceptionHandler);
signal(SIGBUS, SignalExceptionHandler);
signal(SIGPIPE, SignalExceptionHandler);
void SignalExceptionHandler(int sig)
{
NSMutableString *stackInfo = [[NSMutableString alloc] init];
[stackInfo appendString:@"Last Exception Backtrace:\n\n"];
void* callstack[128];
int i, frames = backtrace(callstack, 128);
char** strs = backtrace_symbols(callstack, frames);
for (i = 0; i <frames; ++i) {
[stackInfo appendFormat:@"%s\n", strs[i]];
}
}
但这里会将信号不断的发向该处理函数,导致应用无法正常崩溃,因为一般的消息处理会向进程终结,但是这里没有,所以还会有同样地信号不断的发过来并被处理.所以处理函数后要终结该处理函数的处理,并将其由系统默认处理,即:
signal(sig, SIG_DFL);
而对于有些时候,在iOS中,在应用崩溃后,保持运行状态而不退出:
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);
while (!dismissed)
{
for (NSString *mode in (__bridge NSArray *)allModes)
{
CFRunLoopRunInMode((__bridge CFStringRef)mode, 0.001, false);
}
}
CFRelease(allModes);
应用以上代码,可以做到崩溃时弹框提示应用,以让用户还是可以正常操作,让响应更加友好.Demo
这里最关键的一步，SignalHandler不要在debug环境下测试。因为系统的debug会优先去拦截。我们要运行一次后，关闭debug状态。应该直接在模拟器上点击我们build上去的app去运行。而UncaughtExceptionHandler可以在调试状态下捕捉。
多个Crash日志收集服务共存的坑
自己的程序里集成多个Crash日志收集服务实在不是明智之举。通常情况下，第三方功能性SDK都会集成一个Crash收集服务，以及时发现自己SDK的问题。如果同时有多方通过NSSetUncaughtExceptionHandler注册异常处理程序，会导致程序发生exception的时候不知道调用了哪一个handler而导致错误。
参考：
1、iOS异常捕获
2、获取 iOS crash log(分析得很详细)
