導語
什麼是熱修複？熱修複又稱熱更新檔，一般是用事先定義好的接口，從網絡下載下傳代碼并更新用戶端代碼，進而在使用者無感覺、也無需重裝App的情況下，實作動态修複或動态更新。這樣帶來的優勢就是成本低、效率高，快速作用，節省應用釋出時間，縮短開發周期，降低開發成本；友善資料統計和測試回報，有利于更好地改進App。
正常的流程：
熱修複流程：
熱修複特點：
- 無需重新發版，實時高效熱修複；
- 使用者無感覺修複，無需下載下傳新的應用，代價小；
- 修複成功率高，把損失降到最低。
一、開源流行方案對比：
如今的熱修複技術可謂是百花齊放，每個産品都各有優勢和特點，不過各自都存在局限性，或不穩定、或更新檔大、或效率低、或接入繁瑣，大部分技術上看起來似乎可行，但實際體驗并不好。大體上從Githup星評能直覺了解到各大平台方案受歡迎程度，即開發者信賴程度。
| 方案名稱 | 方案開發公司 | 開發時間 | Github星評 |
|---|---|---|---|
| Robust | 美團（Java派系） | 2016年 | 2500 |
| Andfix | 阿裡（Native派系） | 2015年 | 5994 |
| Nuwa | 大衆點評(dex檔案更新檔） | 2015年 | 2880 |
| Dexposed | 阿裡（不考慮，需要root權限） | ||
| Amigo | 餓了麼(apk更新檔） | 2016年 | 1231 |
| Tinker | 微信(apk更新檔) | 2016年 | 11259 |
| RocooFix | 百度金融(Nuwa改進版） | 2016年 | 1599 |
1、美團Robust，基于Instant Run的原理相容性高，實時生效，但是apk的體積會增大，so和資源的替換暫時不支援，侵入式打包，且接入複雜。
2、女娲Nuwa，坑比較多，比如不支援Gradle1.5以上、更新檔包沒有簽名校驗、位元組碼注入複雜，維護成本高。
3、QQ空間QZone，相容性高，侵入式，不即時生效，混淆對性能會有一定的影響，且在Art模式下出現記憶體錯亂(是Tinker在MDCC上指出的);
4、餓了麼Amigo，目前使用人數最少，網上可參考資料太少，幾乎查不到優接入經驗和踩坑經驗的文章。
5、RocooFix跟Andfix相似，問題是相容性差，有些機型會失效。
*方案比較來自阿裡百川
| 平台 | HotFix | AndFix | Tinker | Qzone | Robust |
|---|---|---|---|---|---|
| 即時生效 | yes | yes | no | no | yes |
| 性能損耗 | 較小 | 較小 | 較小 | 較大 | 較小 |
| 侵入式打包 | 無侵入式打包 | 無侵入式打包 | 依賴侵入式打包 | 依賴侵入式打包 | 依賴侵入式打包 |
| Rom體積 | 較小 | 較小 | Dalvik較大 | 較小 | 較小 |
| 接入複雜度 | 傻瓜式接入 | 比較簡單 | 比較複雜 | 比較簡單 | 複雜 |
| 更新檔包大小 | 較小 | 較小 | 較小 | 較大 | 一般 |
| 全平台支援 | yes | no | yes | yes | yes |
| 類替換 | yes | yes | yes | yes | no |
| so替換 | yes | no | yes | no | no |
| 資源替換 | yes | no | yes | yes | no |
一、阿裡熱修複
| 方案對比 | Andfix開源版本 | 阿裡Hotfix 1.X | 阿裡Hotfix 最新版 (Sophix) |
|---|---|---|---|
| 方法替換 | 支援，除部分情況 | 支援，除部分情況 | 全部支援 |
| 方法增加減少 | 不支援 | 不支援 | 以冷啟動方式支援 |
| 方法反射調用 | 隻支援靜态方法 | 隻支援靜态方法 | 以冷啟動方式支援 |
| 即時生效 | 支援 | 支援 | 視情況支援 |
| 多DEX | 不支援 | 支援 | 支援 |
| 資源更新 | 不支援 | 不支援 | 支援 |
| so庫更新 | 不支援 | 不支援 | 支援 |
| Android版本 | 支援2.3~7.0 | 支援2.3~6.0 | 全部支援包含7.0以上 |
| 已有機型 | 大部分支援 | 大部分支援 | 全部支援 |
| 安全機制 | 無 | 加密傳輸及簽名校驗 | 加密傳輸及簽名校驗 |
| 性能損耗 | 低，幾乎無損耗 | 低，幾乎無損耗 | 低，僅冷啟動情況下有些損耗 |
| 生成更新檔 | 繁瑣，指令行操作 | 繁瑣，指令行操作 | 便捷，圖形化界面 |
| 更新檔大小 | 不大，僅變動的類 | 小，僅變動的方法 | 不大，僅變動的資源和代碼 |
| 服務端支援 | 無 | 支援服務端控制 | 支援服務端控制 |
1、AndFix（開源）：阿裡熱修複從支付寶推出AndFix熱修複方案的引起業界廣泛關注。Andfix是一種Native底層結構替換的方案，達到了運作時生效即時修複的效果。但Andfix本身具有局限性，且不說其底層固定結構的替換方案穩定性不好，其使用範圍隻提供了代碼層面的修複，對于資源和so的修複都還未能實作。
優點：
1. 不侵入打包, 性能無損耗；
2. 即時生效。
缺點：
1. 需要考慮指令集的相容問題，需要native代碼支援，相容性上會有一定的影響；
2. 不支援新增類方法和字段，以及修改<init>方法，也不支援對資源和so的替換。
2、Hotfix（不開源）：阿裡百川結合手淘在實際工程中使用Andfix的經驗，對相關業務邏輯解耦後，推出了阿裡百川Hotfix方案。能夠真正做到BUG即時修複使用者無感覺，同時保證對應用性能不産生不必要的損耗，對于基本的代碼修複需求都可以解決，安全性和易用性都做的比較好。但是HotFix.1.0仍然不支援資源、So檔案修複；不支援新增類方法/類字段。HotFix2.0更新打破限制。
HotFix2.0總體來說最大的優勢在于：
- 更新檔即時生效，不需要應用重新開機；
- 靈活切換熱部署和冷部署的方案；
- 實作了資源、SO檔案、類修複的實時生效;
- 更新檔包體積小，可視化UI界面操作；
- 對應用無侵入，幾乎無性能損耗；
- 相容Android所有機型，傻瓜式接入。
産品收費問題，阿裡百川HotFix在2.0版本的規劃完全實作前完全免費，可放心使用。
3、Sophix（Hotfix3.0）：在2017年6月11日，手淘技術團隊聯合阿裡雲正式釋出了史上首個非侵入式移動熱更新解決方案。核心設計是非侵入性，即不添加任何超出開發者預期的代碼，以避免多餘的熱修複代碼給開發者帶來困擾，給了開發者最大的透明度和自由度，接入成本在所有方案裡最低的。
Sophix提供了一套更加完美的用戶端服務端一體的熱更新方案，做到了圖形界面一鍵打包、加密傳輸、簽名校驗和服務端控制釋出與灰階功能，讓你用最少的時間實作最強大可靠的全方位熱更新。這也是Hotfix3.0開始收費的原因。
下面是Sophix與Tinker和Amigo方案對比：
目前，Sophix在各個名額上全面占優。唯一不足的是不支援的地方就是四大元件的修複。這是因為如果要修複四大元件，必須在AndroidManifest裡面預先插入代理元件，并且盡可能聲明所有權限，而這麼做就會給原先的app添加很多臃腫的代碼，對app運作流程的侵入性很強。
産品收費标準介紹:
官方文檔
它有一個收費閥值 ,超過這個門檻值會從賬戶扣除費用。
每個賬号，每月5萬台裝置免費。
每個賬号，平均到每台裝置，一天免費調用20次。
更新檔包使用，完全不做限制。不額外計費。
二、Tinker （微信開源熱修複）
選擇Tinker的理由很簡單，它自己的介紹夠自信：官方介紹https://github.com/Tencent/tinker/wiki
Tinker已運作在微信的數億Android裝置上，那麼為什麼你不使用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體積 | 較大 | 較小 | 較小 | 較小 |
| 成功率 | 較高 | 較高 | 一般 | 最高 |
優點：
- 項目成熟，文檔健全；
- 內建簡單；
- 支援資源檔案和so檔案的修複替換。
由于原理與系統限制，Tinker有以下已知問題：
- Tinker不支援修改AndroidManifest.xml，Tinker不支援新增四大元件(1.9.0支援新增非export的Activity)；
- 由于Google Play的開發者條款限制，不建議在GP管道動态更新代碼；
- 在Android N上，更新檔對應用啟動時間有輕微的影響；
- 不支援部分三星android-21機型，加載更新檔時會主動抛出"TinkerRuntimeException:checkDexInstall failed"；
- 對于資源替換，不支援修改remoteView。例如transition動畫，notification icon以及桌面圖示。
修複原理：通過新舊apk比較，使用gradle從插件生成.dex更新檔檔案（并不是真正的dex檔案），更新檔通過伺服器下發後嘗試對dex檔案二路歸并進行合并，最終生成全量的dex檔案，與生成更新檔互為逆過程，生成全量dex檔案後進行optimize操作，最終生成odex檔案。在Application中進行反射調用已經合成的dex檔案。
另外，有一個第三方平台TinkerPatch，幫助 Tinker 使用者有一個背景可以下發和管理更新檔包，并且需要處理傳輸安全等部署工作，提供了更新檔背景托管，版本管理，保證傳輸安全等功能，讓你無需搭建一個背景，無需關心部署操作，隻需引入一個 SDK 即可立即使用 Tinker，傻瓜式接入，實時監控。
收費問題：