andfix采用native hook的方式，這套方案直接使用dalvik_replacemethod替換class中方法的實作。由于它并沒有整體替換class, 而field在class中的相對位址在class加載時已确定，是以andfix無法支援新增或者删除filed的情況(通過替換init與clinit隻可以修改field的數值)。andfix可以支援的更新檔場景相對有限，僅僅可以使用它來修複特定問題。
)二. qzone（插樁方式）
該方案基于的是android dex分包方案的, 簡單的概括一下，就是把多個dex檔案塞入到app的classloader之中，但是android dex拆包方案中的類是沒有重複的，如果classes.dex和classes1.dex中有重複的類，當用到這個重複的類的時候，系統會選擇哪個類進行加載呢？ ?讓我們來看看類加載的代碼：
一個class
loader可以包含多個dex檔案，每個dex檔案是一個element，多個dex檔案排列成一個有序的數組dexelements，當找類的時候，會按順序周遊dex檔案，然後從目前周遊的dex檔案中找類，如果找類則傳回，如果找不到從下一個dex檔案繼續查找。
理論上，如果在不同的dex中有相同的類存在，那麼會優先選擇排在前面的dex檔案的類，如下圖：
在此基礎上，我們構想了熱更新檔的方案，把有問題的類打包到一個dex（patch.dex）中去，然後把這個dex插入到elements的最前面，如下圖：
)三. 微信tinker（差量包）
instant run的冷插拔與buck的exopackage或許能給我們靈感，它們的思想都是全量替換新的dex。
我們可以将新舊兩個dex的差異放到更新檔包中，最簡單我們可以采用bsdiff算法。
簡單來說，在編譯時通過新舊兩個dex生成差異path.dex。在運作時，将差異patch.dex重新跟原始安裝包的舊dex還原為新的dex。這個過程可能比較耗費時間與記憶體，是以我們是單獨放在一個背景程序:patch中。為了更新檔包盡量的小，微信自研了dexdiff算法，它深度利用dex的格式來減少差異的大小。
)四、阿裡sophix
原理(雙劍合璧)：
)1.優化andfix（突破底層結構差異，解決穩定性問題）：
andfix底層artmethod結構時采用内部變量一一替換，倒是這個各個廠商是會修改的，是以相容性不好。
sophix改變了一下思路，采用整體替換方法結構，忽略底層實作，進而解決相容穩定性問題。
)2.突破qq和tinker的缺陷
qq和tinker的缺陷