[iOS]LSSafeProtector和Bugly双剑合璧异常处理以及符号表配置

最近工作需要,项目中需要异常检测

LSSafeProtector

LSSafeProtector 是一个可快速集成但功能强大的防止crash库,不改变原代码支持KVO自释放,可以检测到dealloc时未释放的kvo,等19种crash,使用Objective-C编写.

    //注意线上环境isDebug一定要设置为NO)
    [LSSafeProtector openSafeProtectorWithIsDebug:YES block:^(NSException *exception, LSSafeProtectorCrashType crashType) {
        [Bugly reportException:exception];
        //此方法相对于上面的方法,好处在于bugly后台查看bug崩溃位置时,不用点击跟踪数据,再点击crash_attach.log,查看里面的额外信息来查看崩溃位置
        [Bugly reportExceptionWithCategory:3 name:exception.name reason:[NSString stringWithFormat:@"%@  崩溃位置:%@",exception.reason,exception.userInfo[@"location"]] callStack:@[exception.userInfo[@"callStackSymbols"]] extraInfo:exception.userInfo terminateApp:NO];
    }];
    //打开KVO添加,移除的日志信息
    [LSSafeProtector setLogEnable:YES];
    [Bugly startWithAppId:@"5c825b6c8d"];

注意:[Bugly reportExceptionWithCategory:3 name:exception.name reason:[NSString stringWithFormat:@"%@ 崩溃位置:%@",exception.reason,exception.userInfo[@"location"]] callStack:@[exception.userInfo[@"callStackSymbols"]] extraInfo:exception.userInfo terminateApp:NO];

  1. 在IPA包分发(例如蒲公英)时,是会无法获取错误位置的,官方介绍是由于ipa包安装的crash日志是非源码,无法直接分析定位,必须符号化。xcode安装是源码安装。
  2. 在这种自定义汇报情况,Bugly的手动上传符号表也是无法解析的。
  3. 好处是对新手非常友好,能够提示bug位置,而缺点就是以上两个问题,[Bugly reportException:exception];相对来说,可以获取到完整堆栈信息以及得到手动上传符号表的支持(这一点非常重要)。
  4. 还有一个优点,是bugly会把bug归类,标记已解决的问题再次出现时不会有明显提示,且过滤和搜索有些不准确,需要挨个查找。

Bugly

腾讯Bugly,为移动开发者提供专业的异常上报和运营统计,帮助开发者快速发现并解决异常,同时掌握产品运营动态,及时跟进用户反馈。

为什么要配置符号表?
为了能快速并准确地定位用户APP发生Crash的代码位置,Bugly使用符号表对APP发生Crash的程序堆栈进行解析和还原。

举一个例子:
4001.png

符号表配置(只介绍iOS)

推荐使用官方的自动配置

注意点:

  1. 下载符号表提取工具包buglySymbolIOS.jar需放在主目录(Home)的bin目录下(没有bin文件夹,请自行创建);Tips:换电脑打包时需要配置这个工具包
  2. 符号表上传脚本dSYMUpload.sh按官方教程配置到工程里即可,需要修改成自己的APP_ID等信息,完成这两项即配置完成Bugly。Tips:可以自定义查找buglySymbolIOS.jar包的目录以及DEBUG模式是否上传等。
  3. bug上报的数量有待考证,而且会不定程度延迟。(当然一般项目不会有大量bug,不像我们公司每天十几个bug,几百次异常记录)
  4. dSYM符号表文件上传不是一定能成功的!!!!
    触目惊心的上传成功概率

符号表手动上传

使用符号表手动上传的主要目的,是在自动上传失败的情况下辅助解析堆栈信息的。有多种方式可以获取dsym文件,但目前只介绍获取发布版本(也就是Archive后的)的符号表。

  1. 某一版本在Archive后(或在Xcode的Window的Organizer)选择Show In Finder看到的.xcarchive文件,右击显示包内容
  2. dSYMs文件夹内找到项目名称的dSYM文件
  3. 在Bugly页面的符号表管理页面上传,上传完成后,对应版本的问题就可以看到解析后的堆栈信息了。
  4. 另外,如果无法判断是否问题和dSYM文件的版本是否对应,即可从问题具体信息页面进入,查看UUID和找到的dSYM文件的UUID是否一致。查看本地dSYM文件UUID的指令:xcrun dwarfdump --uuid
WX20201027-153231.png
WX20201027-153348.png

总结来说,这双剑合璧是极大程度保护了我们的软件以及定位和解决bug。纯属个人经验之谈,使用过程中难免偏颇,如有纰漏,望指正。

你可能感兴趣的:([iOS]LSSafeProtector和Bugly双剑合璧异常处理以及符号表配置)