騰訊bugly 的crash 上報和umeng的比較
說到crash上傳工具,大家肯定會第一時間想到umeng,不錯,umeng 是最早推出 crash 上報的工具之一,在剛推出來的時候,特別受到ios開發人員的喜愛。
因為個時候,記憶體是手動管理的,很容易發生重複是釋放記憶體導致crash,所以umeng的這個工具能夠上傳已經發布的產品的crash 日誌,非常受開發者喜歡。 雖然現在蘋果推出了ARC了,解放了iOS開發人員的記憶體管理工作,但crash還是不可避免的。
umeng推出 crash上報工具有3年多了,主題核心功能基本沒做大的改進,最近因為需要實時檢視crash 日誌,對,是實時,希望app crash 後,能夠馬上看到錯誤,方便解決crash問題,發現了bugly工具(這個工具還是騰訊提供的,大公司提供的,不會像小的創業團隊,隨時會關閉),
以下是對umeng crash 和 bugly 做的一些對比分析
1. crash 日誌上報的及時性方面
umeng的太慢了,需要1-2小時才能顯示當日的bug,而且有**,每天只能**1000個 crash 日誌,bugly 宣稱的是實時,經過我的測試,比較及時,基本在1分鐘之內就能看到bug 的錯誤
從錯誤的及時性來收,bugly 完勝。
2. 錯誤篩選功能
看下2個頁面的bug 賽選對比
umeng: 版本,型別,以及uuid,作業系統等
我們來看看 bugly的
版本,型別,機型也可以選擇,我最喜歡的功能是使用者功能,紅色標記的地方,因為你可以設定一個id,比如使用者id,uuid等,而不像umeng只有uuid。
查詢bug 方面,bugly要稍微方便些。
3. 錯誤的定位
基本上2者都能提供的比較詳細,但是仍然有些錯誤的提示資訊不夠,相應的堆疊資訊顯示不全。
umeng 提供了錯誤定位工具:詳細請檢視網址,
http://dev.umeng.com/analytics/reports/errors#2
基本步驟是:
(1)將錯誤匯出csv檔案
(2)下載umeng crash分析工具:umcrashtool
(3) 在terminal中執行umcrashtool,提示如下: Usage: umcrashtool [export-file-path],定位後的程式碼及行數會寫入錯誤分析-symbol.csv檔案,與原檔案在同一目錄下。用工具開啟新生成的xxx-symbol.csv檔案,便可檢視錯誤發生的原始碼檔案及行數。
步驟有點麻煩,來看看bugly是怎麼解決的
在 產品->設定->版本管理 可以上傳符號表。
我沒有上傳過符號表,但是看到這個功能,是不是感覺很貼心, 不用自己下載工具,分析。
bugly還提供自動上傳符號表功能,可以在編譯後,自動進行。
具體的功能在bugly高階設定裡 http://bugly.qq.com/iosmore
高階設定里居然還能有錯誤回撥,
在異常發生後進行呼叫,應用可以設定回撥函式,並在回撥中儲存異常現場資訊等資訊,異常現場等資訊可以通過 getCrashXXX 介面獲取
使用示例:
static int exceptioncallbackhandler() { NSLog(@"Crash occur in the app"); [... setAttachLog:@""]; return 1; }
exp_call_back_func=&exception_callback_handler;
看到這個回撥,我想到了知乎還是哪,有篇文章是:“如何讓app 實現優雅的奔潰” 在app 奔潰的時候,提示下使用者:由於不可預知的問題,導致程式奔潰,我們深表歉意。這樣使用者體驗是不是很好!
錯誤定位來看,還是bugly來的方便。
從總體對比來說,bugly還是不錯的,做的相當深入 ,umeng 更定位在統計分析,而crash 上報這塊沒投入太多的精力。
但是bugly也有問題:
(1)產品穩定,靠譜不?
剛推出好像不到2個月吧,看看宣傳
手機QQ,qq瀏覽器 ,各種遊戲什麼的都接入了,你相信嗎?我是不相信的 。
沒有被認可的第三方出名的應用採用這個工具,其穩定性,不曉得。
上百萬,千萬的使用者的應用,使用之前最好還是慎重。
最新訊息,據說,滴滴打車,唯品會也使用了這個
(2)會導致app增加多大?
應用接入會導致app 有多大的增加,因為基本上所有的應用都使用了umeng ,統計是剛需,裡面已經有個crash 上報了,再接入這個bugly 會導致ipa 增加多少,起碼要有個資料。
整個靜態庫有5.1M,應該增加的app的大小比較小吧,這塊沒對比過,應該不超過100K吧。
文章來源:http://appask.cn/article/7
ios開發交流群:486468672