andfix的原理就是方法的替換，把有bug的方法替換成補丁檔案中的方法。
注：在native層使用指標替換的方式替換bug方法，已達到修復bug的目的。
andfix採用native hook的方式，這套方案直接使用dalvik_replacemethod替換class中方法的實現。由於它並沒有整體替換class, 而field在class中的相對位址在class載入時已確定，所以andfix無法支援新增或者刪除filed的情況(通過替換init與clinit只可以修改field的數值)。andfix可以支援的補丁場景相對有限，僅僅可以使用它來修復特定問題。
乙個classloader可以包含多個dex檔案，每個dex檔案是乙個element，多個dex檔案排列成乙個有序的陣列dexelements，當找類的時候，會按順序遍歷dex檔案，然後從當前遍歷的dex檔案中找類，如果找類則返回，如果找不到從下乙個dex檔案繼續查詢。
理論上，如果在不同的dex中有相同的類存在，那麼會優先選擇排在前面的dex檔案的類，如下圖：
在此基礎上，我們構想了熱補丁的方案，把有問題的類打包到乙個dex（patch.dex）中去，然後把這個dex插入到elements的最前面，如下圖：
instant run的冷插拔與buck的exopackage或許能給我們靈感，它們的思想都是全量替換新的dex。
我們可以將新舊兩個dex的差異放到補丁包中，最簡單我們可以採用bsdiff演算法。
原理(雙劍合璧)：
1.優化andfix（突破底層結構差異，解決穩定性問題）：
andfix底層artmethod結構時採用內部變數一一替換，倒是這個各個廠商是會修改的，所以相容性不好。
sophix改變了一下思路，採用整體替換方法結構，忽略底層實現，從而解決相容穩定性問題。
2.突破qq和tinker的缺陷
qq和tinker的缺陷
sophix對dex的解決方案
3.資源修復另闢蹊徑
常用方案（instant run技術）：這種方案的相容問題在於替換assetmanager的地方
sophix資源修復方案
4.so修復另闢蹊徑
Android熱修復原理
修復主要是兩種方案,一種是底層替換方案,一種是類載入方案.這兩種方案各有優劣 底層替換方案是在已經載入了的類中直接替換原有方法,實在原來類的基礎上修改.因此無法實現對原有類的方法和字段的增減,因為這樣將破壞原有的類結構 一旦補丁類中出現了方法的增減,會破壞這個類以及整個dex的方法數的變化.方法數的...
Android熱修復原理（二）
阿里系底層熱修復方案特點 修復時，立即生效。但同時帶來各種rom相容問題，也不能做新增field的修復。如sophix andfix阿里系的修復方案 底層替換所操作的指標，實際上是artmethod，在類被載入，類中的每個方法都會有對應的artmethod，它記錄了方法包括所屬類和記憶體位址資訊，a...
Android中熱修復原理及不同框架比較
遇到的問題 setenabledebug true 發布時改為false 改為true時除錯的時候報錯,暫時找不到原因,建議不要寫這行 官方文件首頁 參考1.第一次修復時成功,當第二次修復時只改變補丁檔案不成功,還必須要重新安裝才能成功 2.修改布局不成功 3.類結構不能改變，andfix不支援新增...