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

普通下載普通下載

相關(guān)電子資料下載