最近工作需要，項目中需要異常檢測
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];
- 在IPA包分發（例如
蒲公英）時，是會無法獲取錯誤位置的，官方介紹是由于ipa包安裝的crash日志是非源碼，無法直接分析定位，必須符號化。xcode安裝是源碼安裝。 - 在這種自定義匯報情況，Bugly的手動上傳符號表也是無法解析的。
- 好處是對新手非常友好，能夠提示bug位置，而缺點就是以上兩個問題，
[Bugly reportException:exception];相對來說，可以獲取到完整堆棧信息以及得到手動上傳符號表的支持（這一點非常重要）。 - 還有一個優點，是bugly會把bug歸類，標記已解決的問題再次出現時不會有明顯提示，且過濾和搜索有些不準確，需要挨個查找。
Bugly
騰訊Bugly，為移動開發者提供專業的異常上報和運營統計，幫助開發者快速發現并解決異常，同時掌握產品運營動態，及時跟進用戶反饋。
為什么要配置符號表？
為了能快速并準確地定位用戶APP發生Crash的代碼位置，Bugly使用符號表對APP發生Crash的程序堆棧進行解析和還原。
4001.png
符號表配置（只介紹iOS）
推薦使用官方的自動配置
注意點：
- 下載符號表提取工具包
buglySymbolIOS.jar需放在主目錄（Home）的bin目錄下（沒有bin文件夾,請自行創建）；Tips：換電腦打包時需要配置這個工具包 - 符號表上傳腳本
dSYMUpload.sh按官方教程配置到工程里即可，需要修改成自己的APP_ID等信息，完成這兩項即配置完成Bugly。Tips：可以自定義查找buglySymbolIOS.jar包的目錄以及DEBUG模式是否上傳等。 - bug上報的數量有待考證，而且會不定程度延遲。（當然一般項目不會有大量bug，不像我們公司每天十幾個bug，幾百次異常記錄??）
-
dSYM符號表文件上傳不是一定能成功的！！！！
觸目驚心的上傳成功概率
符號表手動上傳
使用符號表手動上傳的主要目的，是在自動上傳失敗的情況下輔助解析堆棧信息的。有多種方式可以獲取dsym文件，但目前只介紹獲取發布版本（也就是Archive后的）的符號表。
- 某一版本在
Archive后（或在Xcode的Window的Organizer）選擇Show In Finder看到的.xcarchive文件，右擊顯示包內容 - 在
dSYMs文件夾內找到項目名稱的dSYM文件 - 在Bugly頁面的符號表管理頁面上傳，上傳完成后，對應版本的問題就可以看到解析后的堆棧信息了。
- 另外，如果無法判斷是否問題和dSYM文件的版本是否對應，即可從問題具體信息頁面進入，查看UUID和找到的dSYM文件的UUID是否一致。查看本地dSYM文件UUID的指令：
xcrun dwarfdump --uuid <dSYM文件>
WX20201027-153231.png
WX20201027-153348.png
總結來說，這雙劍合璧是極大程度保護了我們的軟件以及定位和解決bug。純屬個人經驗之談，使用過程中難免偏頗，如有紕漏，望指正。
