熱修復方案概述：

1.QQ空間熱修復方案

RocooFix

Nuwa

HotFix

2.native hook的方案

AndFix

阿里百川(未開源)

3.微信熱修復方案

4.手機QQ熱修復方案

QFix：推薦文章QFix探索之路——手Q熱補丁輕量級方案

Tinker是什么

它主要包括以下幾個部分：

1.gradle編譯插件: tinker-patch-gradle-plugin

2.核心sdk庫: tinker-android-lib

3.非gradle編譯用戶的命令行版本: tinker-patch-cli.jar

為什么使用Tinker

當前市面的熱補丁方案有很多，其中比較出名的有阿里的AndFix、美團的Robust以及QZone的超級補丁方案。但它們都存在無法解決的問題，這也是正是我們推出Tinker的原因。

各個Hotfix方案對比總的來說:

1.AndFix作為native解決方案，首先面臨的是穩定性與兼容性問題，更重要的是它無法實現類替換，它是需要大量額外的開發成本的；

2.Robust兼容性與成功率較高，但是它與AndFix一樣，無法新增變量與類只能用做的bugFix方案；

3.Qzone方案可以做到發布產品功能，但是它主要問題是插樁帶來Dalvik的性能問題，以及為了解決Art下內存地址問題而導致補丁包急速增大的。特別是在Android N之后，由于混合編譯的inline策略修改，對于市面上的各種方案都不太容易解決。

而Tinker熱補丁方案不僅支持類、So以及資源的替換，它還是2.X－7.X的全平臺支持。利用Tinker我們不僅可以用做bugfix,甚至可以替代功能的發布。Tinker已運行在微信的數億Android設備上，那么為什么你不使用Tinker呢？

Tinker的已知問題由于原理與系統限制，Tinker有以下已知問題：

a.Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大組件；

b.由于Google Play的開發者條款限制，不建議在GP渠道動態更新代碼；

c.在Android N上，補丁對應用啟動時間有輕微的影響；

d.不支持部分三星android-21機型，加載補丁時會主動拋出”TinkerRuntimeException:checkDexInstall failed”；

e.由于各個廠商的加固實現并不一致，在1.7.6以及之后的版本，tinker不再支持加固的動態更新；

f.對于資源替換，不支持修改remoteView。例如transition動畫，notification icon以及桌面圖標。

如何使用TinkerTinker

為了實現“高可用”的目標，在接入成本上做了妥協。熱補丁并不簡單，在使用之前請務必先仔細閱讀以下文檔：

如何快速接入請參考Tinker 接入指南；

如何自定義類請參考Tinker 自定義擴展；

Tinker的API預覽請參考Tinker API預覽；

其他常見問題，請參考常見問題；

TinkerPatch后臺

補丁平臺支持一鍵傻瓜式接入，使用請參考TinkerPatch平臺文檔。

Tinker 接入指南

gradle接入

gradle是推薦的接入方式，在gradle插件tinker-patch-gradle-plugin中我們幫你完成PRoguard、multiDex以及Manifest處理等工作。

1.添加gradle依賴

在項目的build.gradle中，添加tinker-patch-gradle-plugin的依賴

然后在app的gradle文件app/build.gradle，我們需要添加tinker的庫依賴以及apply tinker的gradle插件.

dependencies {

//可選，用于生成application類

//tinker的核心庫

......

//apply tinker插件

apply plugin: 'com.tencent.tinker.patch'gradle

參數詳解

我們將原apk包稱為基準apk包，tinkerPatch直接使用基準apk包與新編譯出來的apk包做差異，得到最終的補丁包。

這個地方，對比官方文檔和官方提供的demo來學習時，很明顯感覺到比較繁瑣，但為了嚴謹和后面維護少出問題，還是請大家仔細閱讀和詳細分析官方demo的配置步驟；

tinkerPatch task詳解

直接使用

task:tinkerPatchVariantName(例如tinkerPatchDebug、tinkerPatchRelease)

即可自動根據Variant選擇相應的編譯類型，同時它還貼心的為我們完成以下幾個操作：將TINKER_ID自動插入AndroidManifest的meta項，輸出路徑為build/intermediates/tinker_intermediates/AndroidManifest.xml;

如果minifyEnabled為true，將自動將Tinker的proguard規則添加到proguardFiles中，輸出路徑為build/intermediates/tinker_intermediates/tinker_proguard.pro，這里你不需要將它們拷貝到自己的proguard配置文件中;如果multiDexEnabled為true，將自動生成Tinker需要放在主dex的keep規則。

在tinker 1.7.6版本之前，你需要手動將生成規則拷貝到自己的multiDexKeepProguard文件中。

例如Sample中的multiDexKeepProguard file(“keep_in_main_dex.txt”)。

在1.7.6版本之后，這里會通過腳本自動處理，無須手動填寫。

把dexOptions的jumboMode打開。輸出路徑為：build/intermediates/tinker_intermediates/tinker_multidexkeep.pro。

然后你可以在build/outputs/tinkerPatch中找到輸出的文件。

多Flavor打包有的時候我們希望通過flavor方式打包，在sample中提供了簡單的用法事例：

1.通過flavor編譯，這個時候我們可以看到bakApk路徑是一個按照flavor名稱區分的目錄；

2.將編譯目錄路徑填寫到sample中tinkerBuildFlavorDirectory，其他的幾個字段不需要填寫，這里會自動根據路徑拼接;123ext { tinkerBuildFlavorDirectory = "$/app-1014-13-35-12"}

3.運行tinkerPatchAllFlavorDebug或者tinkerPatchAllFlavorRelease即可得到所有flavor的補丁包。

輸出文件詳解在tinkerPatch輸出目錄build/outputs/tinkerPatch中，

我們關心的文件有：

文件名 描述

patch_unsigned.apk 沒有簽名的補丁包

patch_signed.apk 簽名后的補丁包

patch_signed_7zip.apk 簽名后并使用7zip壓縮的補丁包，也是我們通常使用的補丁包。但正式發布的時候，最好不要以.apk結尾，防止被運營商挾持。

log.txt 在編譯補丁包過程的控制臺日志

dex_log.txt 在編譯補丁包過程關于dex的日志

so_log.txt 在編譯補丁包過程關于lib的日志

tinker_result 最終在補丁包的內容，包括diff的dex、lib以及assets下面的meta文件

resources_out.zip 最終在手機上合成的全量資源apk，你可以在這里查看是否有文件遺漏

resources_out_7z.zip 根據7zip最終在手機上合成的全量資源

apktempPatchedDexes 在Dalvik與Art平臺，最終在手機上合成的完整Dex，我們可以在這里查看dex合成的產物。

每次編譯結束，我們都應該查看相關日志，清楚最終在補丁包中的文件。尤其是dex的補丁文件，即使是1k的dex補丁文件，也會帶來合成時的時間損耗以及合成完整dex文件ROM空間體積這兩部分影響！

TinkerPatch補丁管理后臺

>動手能力強的同學，可以自己按照wiki中的步驟一點一滴的逐步學習；需要提醒大家的是：如果遇到問題，提issue前一定先參考下這個Tinker-常見問題，否則，issue都不會被關注而是直接關閉的；懶得動手的話，可直接接入tinker的第三方平臺，參考接入文檔,有免費版和收費版兩種可供選擇。

堅持原創技術分享，您的支持將鼓勵我繼續創作！