1 模塊化 將我們項目中一些公共的功能單獨的抽取出來，形成一個獨立的，可以被公用的模塊。通常在Android開發(fā)中，我們用AS新建的一個Module就可以看作是一個模塊。

為什么要是用模塊化？ 因為隨著項目的不斷擴張，功能越來越多，項目回越來越大。我們一直提倡kiss原則，就是提倡簡單。所以就需要化繁為簡，把項目可以拆成一些相對較小的模塊，這樣保持簡單的同時，也能夠做到單一職責(zé)原則。

2組件化：組件化是依賴模塊化的。我們把項目化繁為簡，拆成不同的功能模塊，各個模塊都可以完成一個獨立業(yè)務(wù)功能，但是怎么把這些相互獨立又相互配合的獨立業(yè)務(wù)組合在一起，那就又出現(xiàn)了組件化的概念。

因為大型的app一般都是多人開發(fā)，每一個模塊都是相應(yīng)的人員單獨負責(zé)，所以這些模塊在調(diào)試測試階段可以單獨進行編譯測試，這樣即能讓模塊進行單元測試，也能提高編譯時間。各個獨立的模塊都測試通過了，然后在最后的打包發(fā)版階段，把這些獨立的模塊在一起打包成一個完成的apk包。

組件化過程中一個核心的問題就是各個模塊之間的相互通信問題。因為各個模塊之間是不會之間相互依賴的。想要從A模塊跳轉(zhuǎn)到B模塊， 就需要依賴路由了。（ARoute）。雖然各個模塊之間不會相互依賴，但是都需要依賴我們公共的底層路由模塊。然后通過注解，將所有使用注解標(biāo)注的地方，都添加到一個路由表里面。這樣在模塊之間跳轉(zhuǎn)的時候，就會先去這個路由表中查找對于的目標(biāo)地址，找到后就可以跳轉(zhuǎn)過去了。（Flutter也是這么處理的）

3插件化：插件化也是依賴于組件化的，他與組件化的不同在于不同的插件（就是那些模塊）都是一個單獨的apk包。每個插件都是可以單獨安裝運行的。那這又有什么好處呢？

像微信，支付寶這樣的超級app，他除了自己的功能業(yè)務(wù)之外，里面也放了很多第三方的app的相關(guān)鏈接，如果把這些第三方的app都做成獨立的組件，那整個微信或者支付寶打包出來的包就會非常的大，這個顯然不現(xiàn)實。但是使用插件話就可以解決這個問題。這些單獨的功能apk都是可以單獨運行的。我們在打包的時候只需要把我們的核心組件打包發(fā)版就可以了。如果有的用戶需要使用里面的其他服務(wù)，到時候在下載一個輕量級的apk，然后加載進來就可以了。

這里的動態(tài)加載就需要用到一個APK的動態(tài)加載機制了，熱修復(fù)的原理也是一樣的。需要用到Android中的ClassLoader

這又需要從一個Java文件如果被加載到j(luò)vm內(nèi)存中說起了

一個Java文件需要先被編譯成class文件，然后在用到的時候被ClassLoader加載到j(luò)vm中。Java中的ClassLoader采用的是雙親委推機制進行類加載的。Java中通常有三個默認(rèn)的ClassLoader， 分別是AppClassLoader ExtClassLoader，BootstrapClassLoader.雙親委推機制就是當(dāng)一個類需要加載的時候，先調(diào)用AppClassloader，這個時候會先判斷這個類有沒有被加載進來，如果加載了，就創(chuàng)建相應(yīng)的對象，如果沒有，先會委托給ExtClassLoader去加載這個類，Ext和BootStrap這兩個加載器都是從指定的目錄中加載，如果能從指定的目錄中找到相應(yīng)的class文件，那就加載，找不到，最后再回來讓AppClassLoader加載。

Android中的類加載器分為兩個，PathClassLoader 和 DexClassLoader， Path就是從我們apk 的安裝目錄加載相應(yīng)的dex，DexClassLoader可以從任意路徑下面加載，所以當(dāng)我們下載一個新的apk到手機中的SD卡中后，就可以使用DexClassLoader加載里面的dex文件了。

Tinker的熱修復(fù)就是利用的這個原理來實現(xiàn)的熱修復(fù)。