Android開發中，熱修復技術被越來越多的開發者使用，市面上也出現很多成熟的開源框架。但對大部分開發者來說，熱修復依然是一個既熟悉又陌生的詞。僅僅知道熱修復的作用，會使用框架，那樣意義並不大。我們還要知道熱修復的原理，這樣不管框架如何變化，只要基本原理不變，我們都可以快速掌握它，或者自己動手寫一個適合項目的熱修復框架。
熱修復介紹
1.開發流程
當項目出現緊急bug時，傳統的開發流程是發佈新版本，引導用戶覆蓋安裝。拋開平臺審覈上線的時間不說，一天重複下載安裝至少兩次的用戶體驗是很差的。而熱修復的出現完美解決了這個問題，用戶在收到服務器推送過來的修復包後，在項目運行時進行修復。整個過程是在用戶無感知狀態下完成，也無需下載相對來說較大的安裝包，代價小。
總結爲兩個優點：
- 無需重新發版，修復效率高
- 用戶無感知，代價小
2.都能修復什麼
- 資源修復
- 代碼修復
- so庫修復
3.代碼修復技術分類
目前最主要有三種方案：
- 基於類加載與 Dex 分包方案，進行 Dex 插樁/替換
- Native Hook 進行底層替換
- Install Run 進行類的注入
由於國內手機廠商定製系統的多樣，Dex 插樁/替換是我認爲最適合的方案。
Dex插樁原理
ClassLoader 是通過調用 findClass 方法，在 pathList 對象中的 dexElements[] 中遍歷dex文件尋找相關的類。由於靠前的dex會優先被系統調用，所以就有了插樁的概念。將修復好的 dex 插入到 dexElements[] 的最前方，這樣系統就會調用修復好的插入類而不是靠後的 bug 類。
上圖中，patch.dex 是插入的 dex ，classes2.dex 是原有的 bug dex。ClassLoader 在遍歷時優先獲取了 patch.dex 中的 D.class ,所以 classes2.dex 中的 D.class 就不會被調用，這樣就完成了對 D.class 的替換，修復了bug。
本文簡單介紹了代碼修復的技術原理，下篇文章將從系統源碼入手，結合我自己封裝的代碼修復開源框架Fettler，詳細解讀代碼修復的每一個過程。本文如果有出現錯誤的地方也請幫忙在評論區指出，共同學習進步，謝謝大家。