Bugly熱更新采用Tinker開源方案，官方文檔如下：
Bugly Android熱更新使用指南
Bugly Android熱更新詳解
接入熱更新
我們的章魚App之前就已經(jīng)接入了Bugly疤苹，所以添加熱更新支持互广，只需在gradle文件中進行如下更改即可。
/// 注釋掉之前的bugly
//"bugly": 'com.tencent.bugly:crashreport:latest.release', //日志統(tǒng)計
// 添加支持熱更新的 bugly
"bugly": 'com.tencent.bugly:crashreport_upgrade:latest.release', //日志統(tǒng)計（1.3.4之前含Tinker熱更新，現(xiàn)已剝離）
"tinker": 'com.tencent.tinker:tinker-android-lib:1.9.8', //Tinker熱修復(fù)
此外惫皱，我們還需要在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目錄下的文件既不穩(wěn)定也不會同步到git服務(wù)器觉啊。這很容易讓我們發(fā)布線上包后丟失關(guān)鍵文件(用于生成對應(yīng)補丁包的文件)拣宏，即打包后在 app/build/bakApk/日期 目錄下生成的如下文件：
app-release.apk （必有，預(yù)發(fā)布為app-prerelease.apk ）
app-release-mapping.txt （開啟混淆后會有）
app-release-R.txt （必有杠人，預(yù)發(fā)布為app-prerelease-R.apk ）
這些文件大多數(shù)時候是無用的勋乾，每次運行項目或打包都會生成。我們真正需要的是線上包對應(yīng)的這些文件嗡善。
所以辑莫，讓tinker-support生成文件的路徑不變，將待修復(fù)apk的目錄修改為 app/bakApk/app-last-release 罩引。
這樣各吨，每次我們發(fā)布線上包后，將上述生成文件復(fù)制一份并替換到 app/bakApk/app-last-release 目錄下即可袁铐。
自動修改tinkerId
每次打補丁或發(fā)布線上包揭蜒，都需要修改tinkerId，并保證其唯一性昭躺。 我們采用如下格式：
"r" + generateDate()
例如 r-05301455 忌锯。
提供便利的測試（配置 tinker-support-prerelease.gradle 文件）
以上兩項配置保證了線上補丁發(fā)布的便利性，但在發(fā)布線上補丁前领炫，我們希望對事情有所掌控偶垮。這時，我們可以先測試預(yù)發(fā)布環(huán)境補丁效果。
為了方便似舵，將 tinker-support.gradle 復(fù)制一份命名為 tinker-support-prerelease.gradle 脚猾，將其基準包目錄修改為 app/bakApk/app-last-release ，并修改相應(yīng)文件名砚哗。
為了使tinkerId唯一且與線上補丁保持差異龙助，采用如下格式：
"pr" + generateDate()
例如 pr-05301455 。
最后蛛芥，在 app/build.gradle 文件中做如下修改（定義isReleaseTask()方法用于判斷是否為正式環(huán)境）提鸟，根據(jù)任務(wù)類型自動引入相對應(yīng)的tinker-support配置。
if (isReleaseTask(gradle.startParameter.taskNames))
apply from: 'tinker-support.gradle'//tinker線上配置
else
apply from: 'tinker-support-prerelease.gradle' //tinker測試預(yù)發(fā)布包補丁配置仅淑。
發(fā)包清單
- 修改gradle配置称勋，如versionName, versionCode等(tinker-support文件切換及tinkerId修改已自動化)；
- walle打包（Tinker支持walle多渠道包熱修復(fù)）涯竟；
- 將剛才 app/build/bakApk/日期 目錄下生成的文件備份到 app/bakApk/app-last-release 目錄（切記赡鲜，只有確認發(fā)布的線上包才這么做）；
- 打tag庐船，并將代碼提交至服務(wù)器银酬。
發(fā)補丁清單
Tinker補丁不具有即時性，需要app收到補丁后下次啟動才會生效筐钟。
Tinker補丁支持修改gradle文件與資源文件揩瞪。建議補丁與基準包(待修復(fù)包)保持一致的versionName, versionCode。
此外篓冲，Tinker對Manifest的修改支持性不好壮韭，建議補丁包別動Manifest，若需要改動纹因，請先在預(yù)發(fā)布環(huán)境下測試補丁的效果。
補丁發(fā)布步驟：
- 待發(fā)布代碼測試通過琳拨；
- 生成預(yù)發(fā)布環(huán)境補丁包瞭恰；
- 發(fā)布預(yù)發(fā)布環(huán)境補丁包并觀察效果；
——若3順利通過狱庇，則繼續(xù)向下執(zhí)行惊畏，否則break。 - 生成線上補丁包密任；
- 灰度發(fā)布線上補丁包并觀察效果颜启；
——若5順利通過，則繼續(xù)向下執(zhí)行浪讳，否則break缰盏。 - 全量發(fā)布線上補丁包。
第2、3步是對補丁是否能生效的測試口猜，約耗時15～30分鐘负溪。理論上這兩步是可以省去的，在你確保改動代碼被Tinker支持的情況下济炎。不過川抡，不建議如此，熱修復(fù)依然存在許多問題须尚，在預(yù)發(fā)布環(huán)境先行測試補丁效果具有必要性崖堤。
如何生成補丁
線上補丁與測試補丁生成的差異主要體現(xiàn)在配置上。
生成測試補丁
將代碼切回至有問題的線上節(jié)點耐床。
在此配置下使用walle打 prerelease 包密幔，并備份剛剛在 app/build/bakApk/日期 目錄下生成的基準文件。
安裝剛剛生成的基準apk（即代碼等同于線上包的debug包）咙咽；
代碼切回到待發(fā)布節(jié)點（前面幾步造成的代碼改動不需要保存）老玛，將第2步備份好的基準文件替換到 app/bakApk/app-last-prerelease 目錄【ǎ——如果早已備份好線上對應(yīng)的測試包蜡豹，且已安裝，則之前步驟都可以省去溉苛。
-
如下圖镜廉，執(zhí)行 buildTinkerPatchPreRelease/buildTinkerPatchDebug 指令生成prerelease/debug補丁。
生成預(yù)發(fā)布補丁
生成線上補丁
因為在打包時已對線上補丁進行備份愚战，所以生成線上補丁比測試補丁更為簡單娇唯，步驟如下。
將代碼切換至待發(fā)布補丁的節(jié)點寂玲。
保證versionName塔插、versionCode與線上版本一致（以免后續(xù)升級有問題）。
執(zhí)行 buildTinkerPatchRelease 指令生成release補丁拓哟。
如何發(fā)布補丁
生成后的補丁位于項目 app/build/outputs/patch/環(huán)境 目錄下想许，其中， patch_signed_7zip.apk 文件即為要發(fā)布的補丁断序。
將 patch_signed_7zip.apk 文件上傳至Bugly指定項目即可流纹。
圖文請參照bugly官方文檔：上傳補丁包到平臺。
觀察補丁情況
每個補丁都對應(yīng)著特定的一個apk违诗，比如前面提到的線上apk或調(diào)試apk漱凝，在裝有該apk的手機上觀察補丁的下發(fā)與生效。補丁生效需app重啟诸迟。
如何驗證茸炒？
為了便于驗證愕乎，在 build.gradle 里添加一個字段 APK_DATE
buildConfigField "String", "APK_DATE", ""${generateDate()}""
這樣，APK_DATE 即為apk的構(gòu)建時間（即我們用指令生成該apk或其最新補丁的時間）扣典；
在設(shè)置頁面連擊版本號7次妆毕，即可觀察到相關(guān)信息 "生成時：" + BuildConfig.APK_DATE。我們根據(jù)該時間信息可以很輕松地判定出當前包是否為補丁包贮尖。
