寫在最前的話，一直聽說熱修復，不錯，最近修復風靡，不明白原理都不行，明白原理了不會用也不行，故打算拿出一些時間去深入瞭解一番
翻閱眾多資料
在此之前先感謝前人的資料提供，
好了
大家和我一起學習吧；
* 首先明白幾個類的載入器:classLoader—->顧名思義，就是用來動態裝載class檔案的。標準的Java SDK中有個ClassLoader類，藉助此類可以裝載需要的class檔案，前提是ClassLoader類初始化必須制定class檔案的路徑。
URLClassLoader,
PathClassLoader,
DexLoader
三個載入器使用不同，首先URLClassLoader是不能使用在Android上

PathClassLoader是在APK檔案生成之後，及在/data/dalvik/cache檔案中存在的，假如檔案不存在的話就會爆出ClassNoFindException*()

那最後一個DexClassLoader根據我翻閱資料來看，應該就是基於它了
好接下來我們瞭解一下名詞解析

什麼是dex : dex檔案是Android平臺上可執行檔案的型別。這時候我百度的時候出現了一個面試題
這裡我簡單提及一下，瞭解的小夥伴可以跳過，不瞭解的可以點選看一下dex檔案和jar檔案的區別是什麼

區別一：dvm執行的是.dex格式檔案  jvm執行的是.class檔案   android程式編譯完之後生產.class
 
檔案，然後，dex工具會把.class檔案處理成.dex檔案，然後把資原始檔和.dex檔案等打包成.apk檔案。apk就是android package的意思。 jvm執行的是.class檔案。
區別二:dvm是基於暫存器的虛擬機器  而jvm執行是基於虛擬棧的虛擬機器。暫存器存取速度比棧快的多，dvm可以根據硬體實現最大的優化，比較適合移動裝置。
區別三：.class檔案存在很多的冗餘資訊，dex工具會去除冗餘資訊，並把所有的.class檔案整合到.dex檔案中。減少了I/O操作，提高了類的查詢速度

嘿，突然發現我居然看懂了，這不就是dex和jar的區別嗎，不是同一個名詞，但是意思大體一致，為啥，你看呀jar只是將.class檔案整合
而我們dex是將.class和資原始檔轉化成.dex，有木有明白了這幾個名詞。

好，接下來我們介紹一下DexClassLoder();首先它有一個4個引數的構找方法
dexPath 是jar,dex檔案所在的路徑
optimizedDirectory 是得到的dex的檔案解壓後放置的位置
libraryPath 是檔案的library的存放路徑，may be null 可是是空啊
parent 父類構造器

講到這兒其實我們應該有明白，我們其實就是要拿DexClassLoader去進行載入在dexElements遍歷之前，去做我們的操作，此時我們還不懂怎麼去工作，小夥伴，不要慌，這裡我給出一個連結，看完試試能不能明白DexClassLoader的使用原理
dexElements：明白這是啥玩意不，看完再點選上邊的連結哈，其中每個dex檔案是一個Element，當需要載入類的時候會遍歷 dexElements，如果找到類則載入，如果找不到從下一個 dex 檔案繼續查詢。
File.separator 小知識補充（就相當與windows下的“/”Linux下的“\”）

看完回來了，原始碼真心看不懂，噁心，，我先去吐會，等會回來再說

沒看懂，，再去看一會

好了，看得差不多了，其實主要是我們跟蹤原始碼的走向一步一步明白到底去幹了什麼，不必要知道每一個方法的意義，只要知道他怎麼去處理的資料，我在這裡就不再贅述了，我們看一下連結中文章的作者對這個DexClassLoader載入的理解，其實靜下心來能夠看明白的

我們可以簡要總結下整個的載入流程，首先是對檔名的修正，字尾名置為”.dex”作為輸出檔案，然後生個一個DexPathList物件函式直接返回一個DexPathList物件，

在DexPathList的建構函式中呼叫makeDexElements()函式，在makeDexElement()函式中呼叫loadDexFile()開始對.dex或者是.jar .zip .apk檔案進行處理，

跟入loadDexFile()函式中，會發現裡面做的工作很簡單，呼叫optimizedPathFor()函式對optimizedDiretcory路徑進行修正。

之後才真正通過DexFile.loadDex()開始載入檔案中的資料，其中的載入也只是返回一個DexFile物件。

在DexFile類的建構函式中，重點便放在了其呼叫的openDexFile()函式，在openDexFile()中呼叫了openDexFileNative()真正進入native層，

在openDexFileNative()的真正實現中，對於字尾名為.dex的檔案或者其他檔案(.jar .apk .zip)分開進行處理：

.dex檔案呼叫dvmRawDexFileOpen()；其他檔案呼叫dvmJarFileOpen()。

在dvmRawDexFileOpen()函式中，檢驗dex檔案的標誌，檢驗odex檔案的快取名稱，之後將dex檔案拷貝到odex檔案中，並對odex進行優化

呼叫dvmDexFileOpenFromFd()對優化後的odex檔案進行對映，通過mprotect置為"只讀"屬性並將對映的記憶體結構儲存在DvmDex*結構中。

dvmJarFileOpen()先對檔案進行對映，結構儲存在ZipArchive中，然後再嘗試以檔名作為dex檔名來“開啟”檔案，

如果失敗，則呼叫dexZipFindEntry在ZipArchive的名稱hash表中找名為"class.dex"的檔案,然後建立odex檔案，下面就和

dvmRawDexFileOpen()一樣了，就是對dex檔案進行優化和對映。

有沒有很開心，最起碼懂了一點什麼，那我們繼續我們的主線

有上邊那些我們知道了dex是根據.class檔案轉化過來的，然後又經dex轉化成了odex，而 dex -> odex 則是針對不同平臺，不同手機的硬體配置做針對性的優化。就是在這一過程中，虛擬機器在啟動優化的時候，會有一個選項就是 verify 選項，當 verify 選項被開啟的時候，就會執行一次校驗，校驗的目的是為了判斷，這個類是否有引用其他 dex 中的類，如果沒有，那麼這個類會被打上一個 CLASS_ISPREVERIFIED 的標誌。一旦被打上這個標誌，就無法再從其他 dex 中替換這個類了。而這個選項開啟，則是由虛擬機器控制的。

下一步
知道大體意思了，但是不明白怎麼去操作這東西，有沒有力不從心的感覺，馬丹，意味著我還要繼續看下去
可是，我發現我看跑題了，看到了一個外掛製作的小Demo,臥槽，我還是決定提出來，因為這個看完你能更明白DexClassLoader的工作原理
外掛架構Demo
程式碼簡單說明
熱修復的詳解

來個結尾：你可以告訴別人你懂原理了，牛逼否

看了這麼一圈終於知道原理了，當別人問起來你對HotFix的理解的時候，你可以瀟灑的說
1，三個ClassLoader的區別，我們採用那個DexClassLoader載入器進行載入
2，這個DexClassLoader有一個四個引數的建構函式，
- 對應著jar,class檔案所在的檔案位置，
- 對應著要指定獲取到的dex檔案放置的位置，
- 對應本地檔案C，C++ 等本地檔案的放置位置，一般設定為null
- 獲取到父類載入器，等等我們是看過原始碼的淫，這裡可以來點文章
3，對dex和jar的區別來點事，dex是將dvm將.class檔案和資原始檔載入成.dex，而那jar是jvm將.class 檔案轉為.jar.
4，DexClassLoader的工作原理是根據傳入的路徑獲取到dex,如果不是dex的話原始碼中處理方式，比如講不是.dex的結尾檔案裝華為.dex，是的就直接返回進行loadDex()；
5，上邊扯了這麼大牛逼，我們迴歸正題，如何進行熱修復，DexClassLoader是將獲取到一個DexEleMents[]的陣列，進行遍歷，這樣就好辦了不是，陣列是可以新增刪除的，嘿嘿，在他遍歷之前我們對陣列新增，這不就解決了嗎，至於真麼新增，根據宿主App,拿到App中的所有類，這裡我們對類進行過濾，拿到需要實現的類，通過ClassReader，ClassWriter,ClassVIstor,去操作這個位元組碼檔案
6，這裡會引出一個問題，就是我們的App都是經過混淆之後釋出的，所以這裡我們呢，就可以在釋出BUG版本儲存的，在 Gradle 外掛編譯過程中，有一個proguardTask，看名字應該就知道他是負責 proguard 任務的，我們可以儲存首次執行時的混淆規則(也就是線上出BUG的包)，這個混淆規則儲存在工程目錄中的一個mapping檔案，當我們需要執行熱修復補丁生成的時候，將線上包的mapping規則拿出來應用到本次編譯中，就可以生成混淆後的類跟線上混淆後的類相同的類名的補丁了。

說在最後的話，大哥大姐過年好啊，轉載之前給個贊啊