使用苹果自带的崩溃收集
1、崩溃报告系统会用NSSetUncaughtExceptionHandler方法设置全局的异常处理器，这是一个苹果官方提供的C函数，接受的参数是一个函数指针，需要自己实现，当发生异常崩溃的时候，函数得到调用，所以我们对于异常的处理都是写在这个函数里，能得到异常的堆栈信息，原因和名称。
但是，并不是所有的程序崩溃都是由于发生可以捕捉的异常的，有些时候引起崩溃的大多数原因如：内存访问错误，重复释放等错误就无法捕捉到，因为这种错误它抛出的是Signal，所以必须要专门做Signal处理
2、void (signal(int, void ()(int)))(int)也是iOS SDK提供的函数，
该函数接受两个参数，一个int型：代表SIGNAL的类型
第二个参数也是一个函数指针，和NSSetUncaughtExceptionHandler的一样，该函数需要我们实现。
当程序发生异常崩溃时，该函数会得到调用。
其中有6种信号(SIGABRT-程序中止命令中止信号、SIGILL--程序非法指令信号、SIGSEGV--程序无效内存中止信号、SIGFPE--程序浮点异常信号、SIGBUS--程序内存字节未对齐中止信号、SIGPIPE--程序Socket发送失败中止信号)设置了处理函数，
其他信号在没有处理函数的情况下，程序可以指定两种行为：忽略这个信号SIG_IGN或者用默认的处理函数SIG_DFL
注意
使用系统自带的崩溃收集，App的崩溃信息都是存储为各种符号，没有对应符号表，无法直接准确定位到对应的类和类的行数位置。
iOS崩溃异常处理(NSUncaughtExceptionHandler)
使用bugly崩溃收集
符号表作用
没有符号表，我们就无法定位崩溃中的符号对应的代码所在的类以及类中的行数位置。我们在每次构建版本、debug的时候，都会生成dSYM后缀名的符号表文件，而我们App在手机上运行的时候，崩溃后产生的崩溃信息，不可能定位到代码的多少多少行，因为这些信息对于App运行是没有意义的，存储在App中势必会增大安装包的体积，所以App的崩溃信息都是存储为各种符号，具体符号代表什么，需要去符号表中查找对应的含义。
我们将构建版本会自动生成的dSYM文件上传到bugly，bugly会自动帮我们找到崩溃符号的含义。
使用Bugly收集并分析App的崩溃信息
网友评论