捕捉異常注意事項

前言

在之前的文章中，我們已經介紹過了捕捉異常的兩種方式，大家感興趣的話可參考以下文章
Bugly捕獲異常並上報
CrashHandler全局捕捉異常
今天來分析下這兩種方式的各自特點。

今天涉及知識

1. 兩種捕捉異常各自特點
2. 聯合使用注意事項

一. 兩種捕捉異常各自特點

通過之前的學習，我們可以瞭解到異常捕捉的特點：

• 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,今天的內容就介紹到這裏了，謝謝大家。