一、類加載方案
　　1、Qzone
　　Qzone的超級熱修復方案是業界最早的熱修復方案之一，原理簡單而巧妙，影響深刻而久遠，在此簡單介紹。Android類加載的源碼如下：
　　
　　可以看出當有多個dex文件時，他們會組成一個有序數組，按順序加載，而對于一個已經加載的Class是不會再次加載的，由此得出熱修復方案：把需要修復的類打包成一個dex文件下發，并在APP啟動時通過反射，將這個dex文件放在dexElements的最前面，這樣修復了的Class就會比有Bug的Class優先加載了。如下圖所示：
　　
　　但在實現過程中，會遇到unexpected DEX problem異常，Qzone方案為了解決這個問題采用了插樁的策略來規避這個異常。實際上，Android系統的檢查和優化都是有其意義的，因此這種方法在Dalvik和Art上都會遇到問題。
　　● 在Dalvik虛擬機，APP在安裝的時候會被執行dexopt操作，同一個dex文件內的Class會被打上CLASS_ISPREVERIFIED標志，而補丁包中的類并沒有打上此標志，因此拋出異常。解決方法就是在第一次打包APK時讓所有類都引用另一個dex文件中的類，這樣所有的類始終不會打上CLASS_ISPREVERIFIED標志，因此補丁包可以順利加載，但是Dalvik虛擬機在檢測到一個類未打上CLASS_ISPREVERIFIED之后會再次在類加載的時候進行dexopt相關的操作，如果一次性加載很多類，速度將明顯變慢。
　　● 在Art虛擬機，dex文件最終會編譯成本地機器碼，在dex2oat時fast *已經將各個類的地址寫死，若補丁包中的類出現字段或者方法的修改，會出現內存地址錯亂，解決辦法是將這個類的父類和調用這個類的類都加入補丁包。但這樣會導致補丁包急劇增大。（實際上要理解清楚這個問題需要熟悉Dalvik和Art的完整流程，并非三言兩語能解釋清楚）
　　這兩個問題都可以解決，但都要付出一些代價：類加載速度或者補丁包大小。
　　2、Tinker
　　如果Qzone沒有上面兩個缺陷，或許就不會有Tinker了。對于微信這樣一個對性能有極高要求的產品來說，Qzone的缺點會被無限放大。在參考Instant Run的冷插拔與buck的exopackage后，Tinker采用了全量替換的策略。全量替換可以避免插樁和地址寫死問題，但是補丁包會很大，因此可以在新舊兩個Dex的差異放在補丁包中，下發到移動端后再在本地合成完整的dex文件。
　　實際上，Tinker保留了Qzone最核心的東西：反射修改dexElements。無論是插入還是替換，本質都是利用了類加載的特點。由于需要下發的全量補丁包體積過大，Tinker采用了后臺求diff，下發diff文件，移動端合成全量包的策略。
　　如果僅此而已，只要有diff/patch算法，就可以開發Tinker了。實際上，確實如此。而Tinker第二個創新之處就是采用了自研的DexDiff算法，大大優化了下發差異包的大小。

普通下載普通下載

相關電子資料下載