Android插件化：從入門到放棄

知乎DroidPlugin
weishu_DroidPlugin
第一種是動(dòng)態(tài)替換，也就是Hook。可以在不同層次進(jìn)行Hook，從而動(dòng)態(tài)替換也細(xì)分為若干小流派。可以直接在Activity里做Hook，重寫getAsset的幾個(gè)方法，從而使用自己的ResourceManager和AssetPath；也可以在更抽象的層面，也就是在startActivity方法的位置做Hook，涉及的類包括ActivityThread、Instrumentation等；最高層次則是在AMS上做修改，也就是張勇的解決方案，這里需要修改的類非常多，AMS、PMS等都需要改動(dòng)。總之，在越抽象的層次上做Hook，需要做的改動(dòng)就越大，但好處就是更加靈活了。沒(méi)有哪一個(gè)方法更好，一切看你自己的選擇。

第二種是靜態(tài)代理，這是任玉剛的框架采取的思路。寫一個(gè)PluginActivity繼承自Activity基類，把Activity基類里面涉及生命周期的方法全都重寫一遍，插件中的Activity是沒(méi)有生命周期的，所以要讓插件中的Activity都繼承自PluginActivity，這樣就有生命周期了。

第三種是Dex合并，Dex合并就是Android熱修復(fù)的思想。剛才說(shuō)到了兩個(gè)項(xiàng)目——AndFix和Nuwa，它們的思想是相同的。原生Apk自帶的Dex是通過(guò)PathClassLoader來(lái)加載的，而插件Dex則是通過(guò)DexClassLoader來(lái)加載的。但有一個(gè)順序問(wèn)題，是由Davlik的機(jī)制決定的，如果宿主Dex和插件Dex都有一個(gè)相同命名空間的類的方法，那么先加載哪個(gè)Dex，哪個(gè)Dex中的這個(gè)類的方法將會(huì)占山為王，后面其他同名方法都替換了。所以，AndFix熱修復(fù)就是優(yōu)先加載插件包中的Dex，從而實(shí)現(xiàn)熱修復(fù)。由于熱修復(fù)的插件包通常只包括一個(gè)類的方法，體量很小，和正常的插件不是一個(gè)數(shù)量級(jí)的，所以只稱為熱修復(fù)補(bǔ)丁包，而不是插件。