◆版權聲明：本文出自胖喵~的博客，轉載必須注明出處。
轉載請注明出處：http://www.cnblogs.com/by-dream/p/5410003.html
前言
早晨接到一個臨時任務，就是嘗試體驗一把Bugtags，然后看看好不好用，大概是實現原理是什么。
大概搜了搜發現這個工具號稱 可以:
極速集成
一行代碼，開啟高效測試
所見即所得提交
在你的應用中直接提交 Bug，方便快捷
自動記錄運行時數據
界面截圖、設備信息、控制台日志、操作步驟，一項也不少
全民參與測試
測試零門檻，產品經理、設計師、客服都能快速參與
看介紹如此牛逼，於是本喵決定給大家介紹一下這個工具
工具簡介
首先還是老樣子，貼出他們官網地址： https://www.bugtags.com/
一、注冊
填寫自己的郵箱，姓名，密碼，綁定手機后就可以啦。注冊成功后，我們新建一個項目：
因為本人對Android比較了解一些，我們暫時先選擇Android這個平台來實踐。
申請完成后，我們可以看到左下角有一個應用信息的區域，紅色方框標出App key需要在代碼中用到，這里我們先標記出來一下
二、下載demo
添加完成之后，網頁端的東西就這么多。於是覺得先下載他們的demo體驗一下是否好用吧。 （ demo地址：https://docs.bugtags.com/zh/start/integrate/index.html ）
下載完成導入Eclipse工程，如下：
注意這里一共兩個工程：第一個就相當於我們自己的App，第二個Lib就是我們在自己的App需要引入的工程。
代碼引入后沒報錯，直接編譯一個到手機上看看效果。
三、編譯
編譯打包后，進入App，如下圖所示
右邊的小球，就是我們加入Bugtags的lib之后出現的一個小懸浮窗，點開之后只有兩個按鈕，操作簡單不復雜。
第二個按鈕是提交bug的按鈕，一會介紹，第一個是登錄按鈕，我們用我們注冊的郵箱進行登錄，此時會提示 "該App沒有加入到你的項目"之類的話，想想也是，我也沒做什么呢，應該和我的平台關聯不起來。
四、一行代碼
還記的第一步我們在網站上看到的應用的信息嗎？
這里App Key就起到了關鍵的作用。我們需要在當年你的App的工程的Application中加入那所謂的一行代碼（如下圖）：
這樣我們就將這個App和我們的網站關聯起來了。
五、登錄
登錄成功后，可以看到我們的網站中的頭像同步到了App中
六、提Bug
接下來說說剛才我們沒講到的 “第二個按鈕（筆和加號）”，點擊此按鈕之后，屏幕被截屏了，此時出現一個對話框：
可以提交bug和建議，並且可以設置bug的等級，以及關注人和bug的描述，完成這些內容后，屏幕上便出現了這個bug的一個描述，當然你可以拖動它或者改變它的一個方向。
當調整好后，我們遍提交這個bug，點擊對號即可提交：
七、展示
提交完bug后，我們去web端平台去看看：
整體來看，在三個區域多出了一些信息，我們點進去看看究竟提交上來的信息都包含些什么：
Ⅰ 設備信息
從內容上看，拿到了一些基本的設備信息，這個不是很難，相信做過一點Android開發的同學應該都知道怎么獲取這些東西，因此這里就不再贅述了。
這里可以自定義的取到一些當時代碼中運行的一些變量的值，一般開發在定位問題的時候通常需要這些數據。這里需要開發在代碼中調用API，然后將自己關心的參數給set上去，set的形式就是一個key-value的形式，如下：
我在這個頁面初始化的地方加入了我關心的三組數據，當我在這個頁面提交bug的時候，就會把這三個信息給我帶上來：
Ⅲ 操作步驟
首先說明一下，后面的一些內容都是面向企業版（要收費）的內容，而我的是個人版，因此這里看不到我自己實時傳上來的，但是可以看到他們上傳上來的一個大概的樣式
如圖所示，我們可到Activity的生命周期的一個過程，以及控件的消息事件。那么它是怎么捕獲到我的這些內容的原因是什么呢？答案就在下方：
沒錯，你需要在重寫你的這個函數之后，在里面加入Bugtags的一段代碼，對於Activity而言，需要在所有的Activity中實現，如果沒有一個基類的Activity，我相信工作量應該是蠻大的。
Ⅳ 控制台日志
這個沒什么好說的，獲取的就是Logcat中的命令，對Logcat還不清除的同學，可以看我的Logcat的博客。
Ⅴ Bugtags日志
這個日志和Logcat的去吧在於，它也是通過API的方法來調用，但是不會出現在Logcat中。這里我個人認為：用戶數據、logcat日志、bugtags日志其實都是上傳一些信息上來，沒有要絕對分開的必要，使用其中一個即可完成，但是如果你想按分類上傳的話，當然這也是一個好的接口提供方法。
Ⅵ 網絡請求
這項功能可以統計到當前應用的所有http的請求，這里可以說一說。目前我們市面上針對網絡的捕獲都是采用抓包的策略，無論是tcpdump或者是fiddler他們抓取的都是對整個手機網絡的一個捕獲，不能細化到應用級別。而Bugtags使用hook技術並且對市面上一些網絡庫（例如okhttp、 android-async-http）也采取對應的處理，因此可以精准到抓取應用級別的一個網絡請求。
Ⅶ 發生崩潰
除了前面提到的一個Bug提交后可以看到的信息，該平台還可以自動捕獲崩潰信息。這里demo中提供了一個模擬發生崩潰的按鈕
點擊之后應用發生崩潰，我們去系統中可以看到步驟到了堆棧信息：
至於如何捕捉到崩潰異常，有興趣的可以看看 UncaughtExceptionHandler 。這里有我同事在github上寫的demo：https://github.com/DrJia/AndroidLogCollector
對於同類型的崩潰，平台也做了匯總，可以看到崩潰的一個影響范圍
以上大概就是我對Bugtags簡單使用和理解
個人評價
截至目前為止，我認為這是我見過的比較好的平台了，不管是易用性、豐富性、美觀性，個人都覺得不錯，當然也有一些值得改進的地方，下面是個人總結：
優點：
1、可以便捷的提交UI性bug；
2、bug管理平台比較完善（還可以自動生成報表）；
3、自動捕獲異常功能比較出彩；
4、捕獲網絡請求數據比較出彩；
待改進：
1、Fragment或者其他一些自定義布局的生命周期無法捕獲;
2、提交bug適合於靜態頁面UI的錯誤類的bug，不適合復雜操作的邏輯性bug提交;
3、無法捕獲到操作第三方步驟（例如拉起微信登錄）;
4、需要兩個手機完成的不太適合（例如閑魚，需要買賣雙方來完成操作）；
5、記錄詳細的步驟時，開發是否願意維護這些代碼；
6、安全性；