熱修復是一個為了即時解決緊急bug的技術。
從傳統的開發流程看 修復一個bug 的流程：
重新發布版本 ——> 使用者下載安裝 —–> bug 修復
此流程 存在 bug修復的不及時、且使用者下載安裝成本較高 等缺陷。

熱更新修復一個bug 的流程：
檢測服務端是否存在 patch —存在—>下載 patch 到本地
|
|
|
載入本地patch
|
|
修復完成
由此可以看出 熱修復 去修復一個bug 較為靈活，具有：無需重新發版，使用者無感知修復，實時高效熱修復 等優勢,(熱修復 更新的內容繞過了 應用市場的檢測，具有一定的風險)
目前市面可供選擇的熱修復方案較多：HotFix、AndFix、sopHix，還有微信與美團推出的各自的熱修復方案， 網上也有較多文章介紹各個熱修復方案的優缺點， 在此是將網上的方案進行總結一下，做個備份。
市面上熱修復方案雖然較多，但其內部實現依賴的是這兩種技術：

1、art_method 替換技術
2、class 類載入技術

採用 art_method 替換技術的方案，具有以下優點：

1、可以即時修復 bug方法，無需冷啟動應用
2、因為patch是以 method 為單位 生成的，所以補丁包較小
3、對應用無侵入，幾乎無效能損耗

但其缺點也較為顯著：

1、不支援新增欄位，以及修改<init>方法，也不支援對資源的替換。
2、如果廠商修改了art，有可能導致 修復失效。

市面上使用art_method 替換技術的方案為： AndFix， 阿里百川的熱修復方案與 SopHix
採用class 類載入技術 方案的優點為：

1、可以實現類的替換，相容性高。
2、可以修復資源與so庫

不足：

1、不支援即時生效，必須通過重啟才能生效。
2、為了實現修復這個過程，必須在應用中加入兩個dex，對於patch.dex來說，修復的類到了一定數量，就需要花不少的時間載入。
3、在ART模式下，如果類修改了結構，就會出現記憶體錯亂的問題。為了解決這個問題，就必須把所有相關的呼叫類、父類子類等等全部載入到patch.dex中，導致補丁包異常的大，進一步增加應用啟動載入的時候，耗時更加嚴重。

市面上使用 類載入技術的方案較多，且各自都針對與 類載入的方案進行了不同的優化：
微信Tinker、HotFix 與 SopHix 應該都用到此方案。

在此將通過對比 HotFix、AndFix、SopHix，來看起優缺點：

[0] 部分情況指的是構造方法、引數數目大於8或者引數包括long,double,float基本型別的方法。
[1] 冷啟動方式，指的是需要重啟app在下次啟動時才能生效。
[2] 對於Andfix能夠支援的程式碼變動情況，都能做到即時生效。而對於Andfix不支援的程式碼變動情況，會走冷啟動方式，此時就無法做到即時生效。
[3] 由於支援了資源和庫，如果有這些方面的更新，就會導致的補丁變大一些，這個是很正常的。並且由於只包含差異的部分，所以補丁已經是最大程度的小了。
[4] 提供服務端的補丁釋出和停發、版本控制和灰度功能，儲存開發者上傳的補丁包。

AndFix
開源：https://github.com/alibaba/AndFix
AndFix 是阿里最早出的 一個熱更新的框架，art_methods 的修復技術就是由此而來的，他的是在native 層實現方法的修復的，他的流程大概為：
1、從服務端獲取patch 包
2、 解析patch 包，獲取new方法，與要替換的類，並以此獲取old 方法。
3、在native 層，使用jni 的 FromReflectedMethod 方法，獲取old 、new 在記憶體中的方法指標
4、將new 、old 方法指標 中的資料對掉。
由此實現了方法替換修復。
他的關鍵方法為：

   void replace_6_0(JNIEnv* env, jobject src, jobject dest) {
//通過Method物件得到底層Java函式對應ArtMethod的真實地址。
art::mirror::ArtMethod* smeth =
        (art::mirror::ArtMethod*) env->FromReflectedMethod(src);
art::mirror::ArtMethod* dmeth =
        (art::mirror::ArtMethod*) env->FromReflectedMethod(dest);
... ...
//把舊函式的所有成員變數都替換為新函式的。
smeth->declaring_class_ = dmeth->declaring_class_;
smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_;
smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_;
smeth->access_flags_ = dmeth->access_flags_;
smeth->dex_code_item_offset_ = dmeth->dex_code_item_offset_;
smeth->dex_method_index_ = dmeth->dex_method_index_;
smeth->method_index_ = dmeth->method_index_;

smeth->ptr_sized_fields_.entry_point_from_interpreter_ =
dmeth->ptr_sized_fields_.entry_point_from_interpreter_;

smeth->ptr_sized_fields_.entry_point_from_jni_ =
dmeth->ptr_sized_fields_.entry_point_from_jni_;

smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ =
dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_;
}

由此可知 AndFix 是在methods 層級進行修復的，可以即時修復，且對apk效能影響較小，因為其開源,可控性較高，且針對業務需要，可以自己進行定製。但其缺陷也較為明顯，如果廠商對art 進行的修改，那麼此 熱修復框架，不會生效, 無法進行 資源與so的修復，且缺少 服務端控制，需要自己搭建服務端， 因為 此方法的侷限性 ， 僅能進行方法層級修復，缺少patch 的安全驗證，無法新增新的方法與欄位，缺陷較多

HotFix
開源：http://www.jianshu.com/p/6f0ae1e364d9
他使用的class 類載入方案, 此方案依賴的 dex 分包技術，他的流程為：
1、下載雲端的patch 包
2、冷啟動應用
3、在開啟引用時，載入本地 patch 包，解析出 patch 包中 dex 檔案
4、將dex 檔案載入到記憶體中
到此修復完成， patch 包中的 dex 檔案，包含了需要修復的類與檔案，因為 如果應用存在多個dex包，系統在呼叫方法時，會遍歷dex 檔案，查詢到對應類，然後去呼叫方法，
class 類載入方案是 將 需要修復的 類搶先載入到，ClassLoader 中的dex 陣列中，遍歷時 會先遍歷到修復後的類，並將其返回，以此達到修復的目的。 其核心是依賴系統的此方法：

/* package */final class DexPathList {
...
public Class findClass(String name, List<Throwable> suppressed) {
        //遍歷該陣列
    for (Element element : dexElements) {
        //初始化DexFile
        DexFile dex = element.dexFile;
        if (dex != null) {
            //呼叫DexFile類的loadClassBinaryName方法返回Class例項
            Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    }       
    return null;
}
...
} 

用class 類載入技術，是類層級上的 修復技術，可以新加欄位，新加方法，且也是開源的，可控性也較高，可以針對需求 自己定製，例如微信的Tinker 方案就是 此技術結合差分包技術實現的，但此方案的缺陷也 較為明顯， 修復的類，會在記憶體中存在2份 ，如果修復的類較多，那麼對記憶體有影響， 且因為是以類為單位制作patch的，patch 較大， 需要冷啟動，且也缺少服務端，需要自己實現。

Sophix
Sophix 是 阿里2017年6月份推出的一款商業化的 熱更新修復方案， 他是從AndFix後的第三次改進更新(第二次為阿里百川的方案)，雖然不開源，但從其介紹來看 應該是在 art_method 替換技術上進行升級並結合 class 載入技術來實現的，在生成patch時 判斷使用那種方案， 在apk 載入patch包時，解析patch包，根據當前patch 包的方案，判斷是否 需要冷啟動。
SopHix 對art_method 替換技術 進行的升級，不再進行old、new 方法指標的繁瑣的替換操作了，直接進行 memcpy操作，將之前一大堆的替換操作凝縮為了：

memcpy(smeth, dmeth, sizeof(ArtMethod));

而獲取 ArtMethod 的大小sizeof(ArtMethod)，是通過自己寫兩個連續的方法，通過方法指標的差值來實現的。
改進後的 art_method 的替換，即使廠商修改art 後也不會有影響，依然會替換成功。

且較為稱道的是，他存在完善的後臺服務端，可以對指定patch 包進行灰度測試，或直接釋出。
但可惜的是不開源啊。