有一段時間沒有更新部落格了，主要是快畢業了，出來實習找工作，現在在一家公司做安卓，今天是上班的第三天，前兩天瞭解了一下專案，現在專案需要增加熱更新方案，於是我研究了一下市場上的開源方案，今天注重講一下騰訊的bugly。（本文只是對bugly的大致流程進行梳理，並對一些常見的錯誤進行解釋，適合看過bugly官方文件但是沒有整合成功的人）
首先說一下市場上常見的幾種開源方案：Tinker、 Qzone、AndFix、Robust。bugly是基於Tinker實現的。
下面有一張他們的對比圖片，是在Tinker的wiki上下載的，由於這幾種框架一直在更新，所以現在的情況不一定是這樣，大家可以去他們各自的主頁檢視，

進入正題，bugly的使用在官方文件中寫的很清楚，我這裡只寫一下每一個步驟的注意事項和我踩過的坑，bugly的匯入步驟如下：

1. 新增外掛依賴，這個步驟沒有什麼好講的，也沒有什麼坑，註釋也寫得很清楚。
2. 初始化SDK，這裡講一下，初始化SDK分為兩張情況：使用原來的Application（enableProxyApplication = true）和改造Application（enableProxyApplication = false）。使用原來的Application沒有什麼好講的，主要就是初始化的引數Bugly.init(this, “900029763”, false)，第二個引數是你在bugly平臺申請的AppId，第三個引數是是否列印log，在我們除錯的時候將他設定為true，他可以檢查我們的應用是否整合成功
   ；改造Application稍微麻煩一點，但這是官方推薦的方案，比較穩定，這裡我們需要兩個類，一個是繼承TinkerApplication的類，還有一個是繼承DefaultApplicationLike的類，並且注意繼承TinkerApplication的類只能實現一個建構函式，其他的操作都要放在繼承DefaultApplicationLike的類中，之前在Application裡的程式碼都要放到這裡。最後強調一點，不要把enableProxyApplication搞錯了 ，否則什麼都沒用。
3. AndroidManifest.xml配置，這一步裡主要是有一個配置FileProvider，如果您的應用想相容Android7.0，那麼這一步是必須的，如果不是可以省略。
4. 混淆配置，這一步沒什麼好講的，根據需求來。

到這裡bugly的配置就完成了，配置沒有什麼大的坑，一步步來就行了。
下面開始正式內容，bugly的使用，官方給的接入流程還是很詳細的：

下面我們就講一下每一個步驟的注意事項：

1. 編譯基準包，也就是你正常釋出的apk包，這裡只需要修改一下tinkerId這個引數，一般的寫法是“base-1.0.1”，注意base關鍵字和版本。我們前面配置了bugly，但是我們怎麼知道有沒有配置成功呢，這時候就可以驗證了，我們將編譯的基準包安裝在裝置上，此時檢視log日誌，如果有下面這句話代表成功了：
   

2. 對基線版本的bug修復，就是把原來的bug修改掉。

3. 根據基線版本生成補丁包，現在來到重點了，這一步的關鍵是修改appName、tinkerId這兩個引數的值，appName就是你原來的有bug的apk所在的目錄，tinkerId是將base修改為patch，版本號不變。生成的補丁包在build/outputs/patch目錄下。
4. 上傳補丁包到平臺，這一步成功就代表你整合完成了，特別注意：上傳補丁包之前首先有bug的apk要聯網上報過資料，否則是匹配不到版本的。

到這裡bugly的使用就結束了，這麼高大上的功能使用起來還是挺簡單的