[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。纯属个人经验之谈，使用过程中难免偏颇，如有纰漏，望指正。