微信Android熱更新Tinker使用詳解（by 星空武哥）
Tinker是什麼
Tinker是微信官方的Android熱補丁解決方案，它支援動態下發程式碼、So庫以及資源，讓應用能夠在不需要重新安裝的情況下實現更新。當然，你也可以使用Tinker來更新你的外掛。
它主要包括以下幾個部分：
- gradle編譯外掛:
tinker-patch-gradle-plugin - 核心sdk庫:
tinker-android-lib - 非gradle編譯使用者的命令列版本:
tinker-patch-cli.jar
為什麼使用Tinker
當前市面的熱補丁方案有很多，其中比較出名的有阿里的AndFix、美團的Robust以及QZone的超級補丁方案。但它們都存在無法解決的問題，這也是正是我們推出Tinker的原因。
| Tinker | QZone | AndFix | Robust | |
|---|---|---|---|---|
| 類替換 | yes | yes | no | no |
| So替換 | yes | no | no | no |
| 資源替換 | yes | yes | no | no |
| 全平臺支援 | yes | yes | yes | yes |
| 即時生效 | no | no | yes | yes |
| 效能損耗 | 較小 | 較大 | 較小 | 較小 |
| 補丁包大小 | 較小 | 較大 | 一般 | 一般 |
| 開發透明 | yes | yes | no | no |
| 複雜度 | 較低 | 較低 | 複雜 | 複雜 |
| gradle支援 | yes | no | no | no |
| Rom體積 | 較大 | 較小 | 較小 | 較小 |
| 成功率 | 較高 | 較高 | 一般 | 最高 |
總的來說:
- AndFix作為native解決方案，首先面臨的是穩定性與相容性問題，更重要的是它無法實現類替換，它是需要大量額外的開發成本的；
- Robust相容性與成功率較高，但是它與AndFix一樣，無法新增變數與類只能用做的bugFix方案；
- Qzone方案可以做到釋出產品功能，但是它主要問題是插樁帶來Dalvik的效能問題，以及為了解決Art下記憶體地址問題而導致補丁包急速增大的。
特別是在Android N之後，由於混合編譯的inline策略修改，對於市面上的各種方案都不太容易解決。而Tinker熱補丁方案不僅支援類、So以及資源的替換，它還是2.X－7.X的全平臺支援。利用Tinker我們不僅可以用做bugfix,甚至可以替代功能的釋出。Tinker已執行在微信的數億Android裝置上，那麼為什麼你不使用Tinker呢？
Tinker的已知問題
由於原理與系統限制，Tinker有以下已知問題：
- Tinker不支援修改AndroidManifest.xml，Tinker不支援新增四大元件；
- 由於Google Play的開發者條款限制，不建議在GP渠道動態更新程式碼；
- 在Android N上，補丁對應用啟動時間有輕微的影響；
- 不支援部分三星android-21機型，載入補丁時會主動丟擲
"TinkerRuntimeException:checkDexInstall failed"； - 由於各個廠商的加固實現並不一致，在1.7.6以及之後的版本，tinker不再支援加固的動態更新；
- 對於資源替換，不支援修改remoteView。例如transition動畫，notification icon以及桌面圖示。
如何使用Tinker
下面就一BuglyTinker的使用方式進行介紹
為什麼使用Bugly熱更新？
因為bugly已經集成了tinker
無需關注Tinker是如何合成補丁的
無需自己搭建補丁管理後臺
無需考慮後臺下發補丁策略的任何事情
無需考慮補丁下載合成的時機，處理後臺下發的策略
我們提供了更加方便整合Tinker的方式
我們通過HTTPS及簽名校驗等機制保障補丁下發的安全性
豐富的下發維度控制，有效控制補丁影響範圍
我們提供了應用升級一站式解決方案
至於如何使用Bugly熱更新看文件就可以了，今天我就說一說官網文件中多渠道補丁的一些錯誤（今天以Bugly1.2.2（tinker1.7.6））為例
在project的build.gradle中新增依賴
配置app build.gradle
這裡要注意，官方給出的project.tinkerPatch.oldApk、project.tinkerPatch.buildConfig.applyMapping、project.tinkerPatch.buildConfig.applyResourceMapping三個配置路徑有錯誤，tinker 1.7.6也存在多渠道打包有bug（和官方溝通後證實了這一點）
我們在進行多渠道打包的時候會執行下面的命令，他打出的補丁包都是一樣的，通過檢視補丁包內的YAPATCH.MF檔案就可以證明，官網表示會在下一個版本中修復
tinker-support.gradle的配置，
配置config.gradle
其他配置
不要忘了混淆，還有關於適配Android7.0系統的配置，這裡就不說了。
接下來我們執行下面的命令開始生成基準包（一定要保留好基準包）
tinkerPatchAllFlavorRelease
生成生產版本的apk後，如果我們發現bug，可以修復bug，然後生成補丁包。
生成完補丁包後，就可以藉助Bugly的熱更新進行修復了，找到我們註冊的app，上傳補丁包
tinker是在我們開啟app的時候去檢查伺服器有沒有補丁包，以及本地有沒有補丁包，如果檢測到了就去下載，然後會在下次啟動app的進行補丁的修復。這樣通過Bugly我們不用去搭建下發補丁包的伺服器了，特別方便。
