iOS 几种常用的 crash log 崩溃信息调试方法

前言:crash log 对 定位崩溃问题 ,并且不容易复现,尤其是及时对appstore 上正在运营的 app 的迭代改进来说 非常重要.  

1 crash两种情况

1.1 测试环境下 追踪bug

1.2 App Store  上应用 追踪bug

     我们主要讨论在App Store  上应用 追踪bug 的情况

2获取crash log信息途径

2.1自己收集,做错误分析 错误趋势:

      收集崩溃信息 存储 上传服务器 (时机可以是再一次打开应用时候同步)

     方法:

            // 将系统提供的获取崩溃信息函数 封装成CrashExceptioinCatcher类方法

            //
            .h
#import <Foundation/Foundation.h>

@interface CrashExceptioinCatcher : NSObject 
+ (void)startCrashExceptionCatch;
@end

//.m
#import "CrashExceptioinCatcher.h"// 提交异常Log信息void uncaughtExceptionHandler(NSException *exception) {
    // 异常Log信息// TODO: 提交服务器收集
    // ....
//    NSArray *arr = [exception callStackSymbols];
//    NSString *reason = [exception reason];
//    NSString *name = [exception name];
//除了可以选择写到应用下的某个文件，通过后续处理将信息发送到服务器等
//不建议发送邮件形式告知程序人员,当数据量足够大,很可能就被当成垃圾邮件屏蔽了//或者调用某个处理程序来处理这个信息也可 但是 要慎重,有时候 闪退本身就是一种保护机制,错误不能继续错误下去 到此就应该戛然而止
}

@implementation CrashExceptioinCatcher

+ (void)startCrashExceptionCatch
{
    // Sets the top-level error-handling function where you can perform last-minute logging before the program terminates.
    NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); //设置异常Log信息的处理
}
//该类方法需要在  “didFinishLaunchingWithOptions”里面调就开始调用,因为我们需要在应用的整个生命周期中都有机会获取crash log 的机会,虽然我们希望自己的程序完美
[CrashExceptioinCatcher startCrashExceptionCatch];

2.2Xcode 工具 

Xcode-Devices中直接查看”测试机 设备的crash log”

在手机 设置-> 诊断与用量-> 诊断与用量数据  里面 有各种应用的crash log,

获取方式:

手机连接电脑, xcode中 Window->Devices->xxx 的iPhone   明细栏目中 有 View Device log 按钮 点击即手机app中的crash log

如图1

图2 crash log 源码(我手机里 选中的这个 是微信的log) 

2.3苹果官方提供的crash log崩溃收集服务

即”获取用户的 crash log” 

这个是需要用户配合的,因为需要用户在手机 中 设置-> 诊断与用量->勾选 自动发送 ,然后在xcode中 Window->Organizer->Crashes 对应的app,就是当前app最新一版本的crash log ,并且是解析过的,可以根据crash 栈 等相关信息 ,尤其是程序代码级别的 有超链接,一键可以直接跳转到程序崩溃的相关代码,这样更容易定位bug出处.

参见图3

2.4第三方:

    2.4.1 友盟”错误趋势 错误分析”  

         这个我正在用,crash log 可读性差,需要配合.dSYM文件 定位可能报错代码位置(下面会详细介绍crash log文件和.dSYM文件 是什么 怎么用)

        网上的确有很牛逼的人,人家直接写了mac程序dSYMTool(具体使用参见参考资料(3))

        简单说就是,我们每次迭代的应用时候,对应版本的.xcarchive文件要保存好备份,配合工具使用,当UUID和友盟里日志一致时候,填写错误信息内存地址,就可得到具体的代码行,即潜在的错误出处.

    2.4.2 Fabric 崩溃检查

        这个我也正在用,它的 crash log直接可读,直接定位可能报错代码位置 (此时没使用友盟错误统计)

    小结:

    不论是自己收集crash还是靠第三方收集,一般一个应用程序只应该有一处调用crash统计,很多第三方为了使自己能够尽可能全面统计crash会对NSSetUncaughtExceptionHandler()函数指针的恶意覆盖，因为这个函数是将函数地址当做参数传递，所以只要重复调用就会被覆盖，这样就不能保证崩溃收集的稳定性。

2.5 命令行解析Crash文件

      //TODO:待补充完善

3 解读 crash log 信息

      未经过二次分析解读的crash log可读性差,参见图2.

      dYSM文件是iOS编译后保存16进制函数地址映射信息的中转文件，每次应用程序build后，都会生成对应的xxx.app, xxx.app.dSYM文件。(所以说 每次封包 xxx.app, xxx.app.dSYM 都是需要备份的文件,方便追溯crash)

       xx.app.dSYM 文件和 友盟 crash log都有自己的 UUID 当二者一致 那么crash 的堆栈信息就一致,查出来的错误内存地址转化成的代码行才相对更准确

      转化成可读的"crash log"如下(友盟为例)

      //TODO:

参考资源:

(1)http://www.cocoachina.com/ios/20151218/14748.html 

(2)http://www.jianshu.com/p/12a2402b29c2

(3)http://www.cocoachina.com/ios/20141219/10694.html

原文：http://www.cnblogs.com/someonelikeyou/p/6379861.html