前言
在之前的文章中,我们已经介绍过了捕捉异常
的两种方式,大家感兴趣的话可参考以下文章
Bugly捕获异常并上报
CrashHandler全局捕捉异常
今天来分析下这两种方式的各自特点。
今天涉及知识
- 两种捕捉异常各自特点
- 联合使用注意事项
一. 两种捕捉异常各自特点
通过之前的学习,我们可以了解到异常捕捉的特点:
- Bugly:能远程上传bug信息,但不便于开发实时观察
- CrashHandler:开发时,可界面实时查看bug信息,但无bug信息记录,若要记录,流程比较繁琐,需要做上传服务器或本地写文件的操作
二. 联合使用注意事项
鉴于这两种异常捕捉各自的特点,我们当然希望一个app中能同时集中这两种捕捉异常
的特性,于是便有了联合使用
的想法。但是在联合使用
的过程中,我们需要注意,当你同时集成
Bugly
和CrashHandler
的时候,Bugly
功能会失效,原因是CrashHandler
会本地拦截bug
信息,导致Bugly
无法获取到错误信息,所以Bugly
上传功能无法执行。
因此,为了更好的集结这两种捕捉异常
的特性,我们一般在测试版
时,使用CrashHandler
捕获,而在正式版
时,采用Bugly
捕获。则在我们项目的自定义Application
的onCreate()
中,我们会做类似如下处理:
//初始化异常捕捉库
CrashConfig.getInstance().init(this)
//true:打开log调试模式,默认为false
.setDebug(AppConfig.isDebug)
//注意:本地crash与bugly不能同时使用,只能二者选一
//通常情况我们测试版使用本地crash方便界面查看,正式版时使用bugly,便于远程查看bug
if(AppConfig.isTest){
//测试版使用本地crash捕捉
//isLocalCrash:boolean类型,true:开启捕捉异常功能 false:关闭异常不做功能,默认为false,但我们一般设置为true
CrashHandler.getInstance().init(isLocalCrash,object:CrashHandler.OnCrashListener{
override fun uploadInfo(info: String?) {
//上传错误到服务器的处理
//......
}
override fun exitApp() {
//退出app
SplashHelper.exitApp()
}
})
}else{
//正式版使用buglyUtil
//appId: bugly注册时申请的APPID,字符串
//debug:boolean类型, 输出详细的Bugly SDK的Log,建议在测试阶段建议设置成true,发布时设置为false
//context: Application实例对象
BuglyUtil.init(appId, debug.isTest, context)
}
这样处理的话,我们就可以兼顾本地开发调试与正式发布使用啦。
ok,今天的内容就介绍到这里了,谢谢大家。