談談bugly的補丁公升級

bugly的補丁公升級時通過tinker實現的，bugly對tinker進行了一層封裝，所以我們不需要關心tinker的實現原理，如何整合bugly的補丁公升級，**如下

dependencies

更詳細的整合文件可以參考bugly,下面著重說下需要注意幾點的。

overridetinkerpatchconfiguration = true//是否啟用覆蓋tinkerpatch配置功能，預設值false //如果是false的話需要新增下面** tinkerpatch

//預設值是false,

//true的情況不需要關注

//false的情況需要如下編碼，**有簡化

public

class

extends

public

"com.tencent.tinker.loader.tinkerloader", false);

}}public

class

extends

@override

public

void

oncreate()

}首先，在tinker-support.gradle檔案裡，你需要修改

tinkerid = "1.0.1-base" //可以通過**自動生成。通過獲取版本號來生成。

在tinker-support.gradle檔案裡，我們需要關注兩個地方

/** * 這個就是我們上面生成的目錄名稱 *///這個跟build/bakapk下面對應的基準包目錄一致 tinkerid = "1.0.1-patch" //也是唯一的，習慣規則跟上面一樣;它和基線包的tinkerid沒有什麼關係，因為這是在打補丁包，所以習慣的規則是加-patch

配置玩這些後，呼叫buildtinkerpatchrelease命令，會生成目錄如下

上傳補丁包需要注意的幾點

a.下發範圍，如下圖

// 設定開發裝置，預設為false，上傳補丁如果下發範圍指定為「開發裝置」，需要呼叫此介面來標識開發裝置

b.停止下發和撤回

撤回，需要注意兩點。一旦撤回，應用過該補丁的版本都會被恢復到原狀態，比如應用補丁之前有bug, 該補丁是用來修復bug，被撤回之後bug會繼續存在；而且補丁一旦測繪，就不能在編輯了，如下圖只能檢視歷史

需要注意的一點，我們安裝的版本是加固後的版本，但是我們在生成補丁包的流程和上面完全一樣【不是想象中的加固後的版本作為基線版本】。

彙總一下，補丁公升級很好用，但是一定要慎重使用。一旦濫用就會導致正常公升級和補丁公升級混亂不堪。推薦場景：發布乙個上線版本，在半天/一天的時間內，如果有問題，趕緊彙總，如果有bug或者非常必要的修改，則發布補丁。切記不要乙個版本發布太多補丁。