這兩天公司專案需要是用熱更新來提升使用者使用體驗，減少由於bug造成的頻繁發版，最後當然選擇使用triker作為熱更新了，不過我還是決定使用bugly，原因如下：

1.bugly熱更新是對trinker的再次封裝，整合起來相對簡單

2.bugly有操控控制檯，我可以很簡單隨意的下發補丁，並且如果補丁不合適我還可以撤回，可以根據不同的版本進行細分下發等等

基於以上兩點我決定選用bugly熱更新了，下面說一下這兩天整合的過程中踩得坑吧：

一.參考文件記錄：

1.https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20170815114059
2.http://m.blog.csdn.net/ou775968876/article/details/76160219
3.https://bugly.qq.com/docs/user-guide/faq-android-hotfix/?v=20170504092424

1.按照官方文件來整合，第四部功能清單其實是可以不用配置的，因為我們基本上都是用的最新的騰訊sdk

2.關於tinkerId，這個其實就是我們每次發版前需要改一下，然後發完版後打補丁的時候再改一次，就改這兩次就好了，直到下一次再發版的時候再重複上述操作例如：

    // 構建基準包跟補丁包都要修改tinkerId，主要用於區分，每次上線時改變一次
    //tinkerId = "base-1.3.6"
    //打補丁時用
    tinkerId ="patch-1.3.6"

多渠道打包基準包的名稱必須要規範，否則會找不到基準包例如app-dev-release.apk
 
，app-main-release.apk

4.打包所用的guadle在AS的右側，展開就可以看到了

  5.最重要的一個就是補丁包的位置：你必須要上傳build/outputs/patch目錄下的補丁包