作为一名开发者，修改bug是一件不可避免的事情，没有永恒的技术，就没有永久坚挺的代码，只有不断的学习改变。
先了解下crash:
crash一般就两种情况：signal（中断，信号量） 和EXC_BAD_ACCESS（异常）
signal分类
查看iOS SDK中断信号有好多...
下面介绍下，实际开发中遇到频率较高的几个：
SIGSEGV**** (Segmentation fault)
访问了没有权限的内存地址（系统内存地址等）
SIGBUS**** (Bus error)
访问了无效的内存地址
SIGFPE**** (Floating point exception)
浮点数运算异常
SIGPIPE
程序Socket发送失败中止信号
SIGILL
非法指令
SIGTRAP
由断点指令或其它trap指令产生. 由debugger使用
SIGABRT
程序中止命令中止信号
EXC_BAD_ACCESS 是我们开发过程中最常见的，简单的说：就是访问了不在的地址值
对我们开发者来说能出现必现的crash是幸福的，因为可以连着Xcode调式，查看crash的堆栈信息。
第一步：打开异常断点,打开这个能找到一般简单的crash点
第2步：点击Product->Edit Scheme，在Run->Diagnostics 打开Zombie Objects（僵尸对象） 选项。针对exc_bad_access 类的crash点是比较好的解决办法。如下图：
一般crash会定位到
*** -[__NSArrayM release]: message sent to deallocated
*** -[ChatViewController respondToSelector]: message sent to deallocated instance
当然xcode7以后多了个 Address Sanitizer，打开这个也是可以的。
crash原因 基本都可以用以上方法定位到了。如果异常输出是地址值，我们可以在Xcode 输出控制台输入命令行：po 0x1000e4000 可以查看到具体的类名
对于不可重现的crash，我们只能通过其他方法。
1.对crash日志文件符号化。
一般我们用发生过crash的手机连接电脑，通过xcode->window->Devices 选中我们的手机 view Device logs,导入crash日志，
在拿到对应App的 .ipa 和.dsym文件，两个放在电脑同一文件，
在对应crash文件右键选择Re-Symbolicate Log，之后能看到原先是我们app内的地址已经变成代码明文.
如何拿到.dsym文件？
打包在Archive的时候会生成.xcarchive文件，然后右键显示包内容就可以看到.dsYM文件和.app文件，一般这个不会删除.xcarchive的。
操作如下图：
如果你是在一些第三方平台(如友盟)上看到crash，可能是crash日志中的发生crash的线程，那时候，你可能就需要自己去符号化对应的类
使用方法如下：
atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
上面的UUID 是指.dsym文件对应的
详细分析参考官方文档：https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION
2.捕获异常日志输出
在代码中添加捕获异常代码，将捕获到的日志打印出来，存入到文档，并在适当的时间上报服务器。Flurry，友盟等第三方应该是类似方法实现的。
下面贴一下代码吧。这个代码也是很早以前网上copy过来的,网上应该也能找到。
#include <libkern/OSAtomic.h>
#include <execinfo.h>
// 系统信号截获处理方法
void signalHandler(int signal);
// 异常截获处理方法
void exceptionHandler(NSException *exception);
const int32_t _uncaughtExceptionMaximum = 10;
void signalHandler(int signal)
{
volatile int32_t _uncaughtExceptionCount = 0;
int32_t exceptionCount = OSAtomicIncrement32(&_uncaughtExceptionCount);
if (exceptionCount > _uncaughtExceptionMaximum) // 如果太多不用处理
{
return;
}
// 获取信息
NSMutableDictionary *userInfo =
[NSMutableDictionary dictionaryWithObject:[NSNumber numberWithInt:signal] forKey:UncaughtExceptionHandlerSignalKey];
NSArray *callStack = [ExceptionHandler backtrace];
[userInfo setObject:callStack forKey:SingalExceptionHandlerAddressesKey];
// 现在就可以上报信息到服务器
}
void exceptionHandler(NSException *exception)
{
volatile int32_t _uncaughtExceptionCount = 0;
int32_t exceptionCount = OSAtomicIncrement32(&_uncaughtExceptionCount);
if (exceptionCount > _uncaughtExceptionMaximum) // 如果太多不用处理
{
return;
}
NSArray *callStack = [ExceptionHandler backtrace];
NSMutableDictionary *userInfo =[NSMutableDictionary dictionaryWithDictionary:[exception userInfo]];
[userInfo setObject:callStack forKey:ExceptionHandlerAddressesKey];
// 现在就可以上报信息到服务器
}
@implementation ExceptionHandler
//获取调用堆栈
+ (NSArray *)backtrace
{
void* callstack[128];
int frames = backtrace(callstack, 128);
char **strs = backtrace_symbols(callstack,frames);
NSMutableArray *backtrace = [NSMutableArray arrayWithCapacity:frames];
for (int i=0;i<frames;i++)
{
[backtrace addObject:[NSString stringWithUTF8String:strs[i]]];
}
free(strs);
return backtrace;
}
// 注册崩溃拦截
-(void)installExceptionHandler
{
NSSetUncaughtExceptionHandler(&exceptionHandler);
signal(SIGHUP, signalHandler);
signal(SIGINT, signalHandler);
signal(SIGQUIT, signalHandler);
signal(SIGABRT, signalHandler);
signal(SIGILL, signalHandler);
signal(SIGSEGV, signalHandler);
signal(SIGFPE, signalHandler);
signal(SIGBUS, signalHandler);
signal(SIGPIPE, signalHandler);
}
@end
总结
在实际开发中要注意以下：
1、防止数组越界 当调用objectAtIndex时注意是否越界
2、指针空的判断，这种crash也是比较常见的，在访问对象之前一要要确保对象存在。
3、NSNotification、Delegate和NSTimer移除，通知、代理和定时器等在使用后一定要记得释放，或最后在dealloc函数中置nil/removeObserve/invalidate 否者很容易发生crash。
NSTimer也可以重新改造一下使用,可参考很久前封装的类https://github.com/weskhen/WeakTimer
4、在跨类调用方法时，或访问API对系统版本有要求时，最好使用respondsToSelector 判断访问，尤其是delegate代理使用。
5、内存管理，在收到内存警告一定要及时释放东西，因为不做处理，很容易被系统杀掉。
6、多线程并发操作引发的crash，在多并发环境中，如果一个线程已经将数据删除，另外一个线程去访问，因数据不存在必然会crash,所以一定要通过加锁机制来解决问题，在初学CoreData数据库时经常遇到过。
参考地址：
http://blog.csdn.net/arthurchenjs/article/details/7049175
