Bugly熱更新採用Tinker開源方案，官方文檔如下：
Bugly Android熱更新使用指南
Bugly Android熱更新詳解
接入熱更新
我們的章魚App之前就已經接入了Bugly，所以添加熱更新支持，只需在gradle文件中進行如下更改即可。
/// 註釋掉之前的bugly
//"bugly": 'com.tencent.bugly:crashreport:latest.release', //日誌統計
// 添加支持熱更新的 bugly
"bugly": 'com.tencent.bugly:crashreport_upgrade:latest.release', //日誌統計（1.3.4之前含Tinker熱更新，現已剝離）
"tinker": 'com.tencent.tinker:tinker-android-lib:1.9.8', //Tinker熱修復
此外，我們還需要在project層級的build.gradle中添加classpath；
接下來添加tinker-support.gradle文件並在app.gradle裏添加配置；
......
不一一描述，這些Bugly官方文檔裏都有。下面主要講接入熱更新後，章魚App項目引起的改動。
改造Application
在 tinker-support.gradle 文件中配置
enableProxyApplication = true
可以避免Application的改動，但爲了更好的兼容性，Tinker官方推薦改造Application。
我們的Application改造前如下圖左半，改造後如下圖右半。
配置tinker-support
一般來說，在改造好Application後，tinker-support.gradle 無需更改即可使用。但爲了在章魚項目下使用起來便捷，進行了如下修改。
修改文件路徑
tinker-support默認指定的文件路徑均位於build目錄下，而build目錄下的文件既不穩定也不會同步到git服務器。這很容易讓我們發佈線上包後丟失關鍵文件(用於生成對應補丁包的文件)，即打包後在 app/build/bakApk/日期 目錄下生成的如下文件：
app-release.apk （必有，預發佈爲app-prerelease.apk ）
app-release-mapping.txt （開啓混淆後會有）
app-release-R.txt （必有，預發佈爲app-prerelease-R.apk ）
這些文件大多數時候是無用的，每次運行項目或打包都會生成。我們真正需要的是線上包對應的這些文件。
所以，讓tinker-support生成文件的路徑不變，將待修復apk的目錄修改爲 app/bakApk/app-last-release 。
這樣，每次我們發佈線上包後，將上述生成文件複製一份並替換到 app/bakApk/app-last-release 目錄下即可。
自動修改tinkerId
每次打補丁或發佈線上包，都需要修改tinkerId，並保證其唯一性。 我們採用如下格式：
"r" + generateDate()
例如 r-05301455 。
提供便利的測試（配置 tinker-support-prerelease.gradle 文件）
以上兩項配置保證了線上補丁發佈的便利性，但在發佈線上補丁前，我們希望對事情有所掌控。這時，我們可以先測試預發佈環境補丁效果。
爲了方便，將 tinker-support.gradle 複製一份命名爲 tinker-support-prerelease.gradle ，將其基準包目錄修改爲 app/bakApk/app-last-release ，並修改相應文件名。
爲了使tinkerId唯一且與線上補丁保持差異，採用如下格式：
"pr" + generateDate()
例如 pr-05301455 。
最後，在 app/build.gradle 文件中做如下修改（定義isReleaseTask()方法用於判斷是否爲正式環境），根據任務類型自動引入相對應的tinker-support配置。
if (isReleaseTask(gradle.startParameter.taskNames))
apply from: 'tinker-support.gradle'//tinker線上配置
else
apply from: 'tinker-support-prerelease.gradle' //tinker測試預發佈包補丁配置。
發包清單
- 修改gradle配置，如versionName, versionCode等(tinker-support文件切換及tinkerId修改已自動化)；
- walle打包（Tinker支持walle多渠道包熱修復）；
- 將剛纔 app/build/bakApk/日期 目錄下生成的文件備份到 app/bakApk/app-last-release 目錄（切記，只有確認發佈的線上包才這麼做）；
- 打tag，並將代碼提交至服務器。
發補丁清單
Tinker補丁不具有即時性，需要app收到補丁後下次啓動纔會生效。
Tinker補丁支持修改gradle文件與資源文件。建議補丁與基準包(待修復包)保持一致的versionName, versionCode。
此外，Tinker對Manifest的修改支持性不好，建議補丁包別動Manifest，若需要改動，請先在預發佈環境下測試補丁的效果。
補丁發佈步驟：
- 待發布代碼測試通過；
- 生成預發佈環境補丁包；
- 發佈預發佈環境補丁包並觀察效果；
——若3順利通過，則繼續向下執行，否則break。 - 生成線上補丁包；
- 灰度發佈線上補丁包並觀察效果；
——若5順利通過，則繼續向下執行，否則break。 - 全量發佈線上補丁包。
第2、3步是對補丁是否能生效的測試，約耗時15～30分鐘。理論上這兩步是可以省去的，在你確保改動代碼被Tinker支持的情況下。不過，不建議如此，熱修復依然存在許多問題，在預發佈環境先行測試補丁效果具有必要性。
如何生成補丁
線上補丁與測試補丁生成的差異主要體現在配置上。
生成測試補丁
將代碼切回至有問題的線上節點。
在此配置下使用walle打 prerelease 包，並備份剛剛在 app/build/bakApk/日期 目錄下生成的基準文件。
安裝剛剛生成的基準apk（即代碼等同於線上包的debug包）；
代碼切回到待發布節點（前面幾步造成的代碼改動不需要保存），將第2步備份好的基準文件替換到 app/bakApk/app-last-prerelease 目錄。——如果早已備份好線上對應的測試包，且已安裝，則之前步驟都可以省去。
-
如下圖，執行 buildTinkerPatchPreRelease/buildTinkerPatchDebug 指令生成prerelease/debug補丁。
![]()
生成線上補丁
因爲在打包時已對線上補丁進行備份，所以生成線上補丁比測試補丁更爲簡單，步驟如下。
將代碼切換至待發布補丁的節點。
保證versionName、versionCode與線上版本一致（以免後續升級有問題）。
執行 buildTinkerPatchRelease 指令生成release補丁。
如何發佈補丁
生成後的補丁位於項目 app/build/outputs/patch/環境 目錄下，其中， patch_signed_7zip.apk 文件即爲要發佈的補丁。
將 patch_signed_7zip.apk 文件上傳至Bugly指定項目即可。
圖文請參照bugly官方文檔：上傳補丁包到平臺。
觀察補丁情況
每個補丁都對應着特定的一個apk，比如前面提到的線上apk或調試apk，在裝有該apk的手機上觀察補丁的下發與生效。補丁生效需app重啓。
如何驗證？
爲了便於驗證，在 build.gradle 裏添加一個字段 APK_DATE
buildConfigField "String", "APK_DATE", ""${generateDate()}""
這樣，APK_DATE 即爲apk的構建時間（即我們用指令生成該apk或其最新補丁的時間）；
在設置頁面連擊版本號7次，即可觀察到相關信息 "生成時：" + BuildConfig.APK_DATE。我們根據該時間信息可以很輕鬆地判定出當前包是否爲補丁包。