概要了解，先要明確這幾個功能具體是做什么的，是為了解決什么問題

1.組件化

組件化首先要做的事是將app按功能模塊進行拆分，降低各個模塊間的耦合，并且可以將每個模塊單獨編譯運行，也可以進行全量打包，可分可合。那說到這里，好處就顯而易見了，在團隊開發中可以讓功能模塊責任到人，各個模塊開發同步進行，增強協作能力以及效率。全量或者拆分運行打包依靠的是gradle的靈活配置能力。

總結：組件化可拆分可全量打包，組件可單獨測試，打包，提高開發效率。

2.插件化

插件化見名知意，像插件一樣可插拔。但是需要提前預留插件的插槽，也就是對應插件的apk。實際開發中，會預先將一個插件打包成一個apk，放置到主module下的assets目錄，而后在運行過程中，如果需要，先將assets目錄下的apk復制到app的目錄下，讀取到插件apk，再通過反射(DexClassLoader)從對應的dex文件中讀取到對應的類進行加載。但是該功能無法直接繞過Android的清單文件注冊（并不絕對，比較麻煩），所以如果進行頁面的加載是不能使用Activity的，只能加載Fragment。當然，預留的插件app也可以通過動態部署的方式去更新放置到app目錄下，故可以變相的減少app的體積，提升用戶體驗。

總結：插件化可以通過動態部署的方式，減少apk體積，增強功能上的靈活性。

注意：插件化對插件的行為是已經預測到的有計劃的。所以會預先留出加載的邏輯，只是相關的類文件首次打包不存在，這也是區別于熱更新的地方。

3.熱更新/熱修復

熱更新主要用于在線上環境，若線上出現bug或者需要更新一些功能，使用熱更新適合的時候進行更新。該行為不需要像插件化一樣預留“插槽”，哪里需要補哪里。

原理：干預（替換，或者增量更新）類加載器加載的dex數組。通過源碼可知，類加載最終會將apk打包好的dex文件寫入到一個“pathList”,這個pathList中包含的即為dex類型的元素。類加載過程中使用所謂的“雙親委派”機制，會優先從加載過的類的緩存中尋找，該pathList即為緩存。所以將需要修復的同名文件打包成dex（使用d8打包），放入到pathList的數組頭部，加載過程中會從頭至尾依次遍歷，若找到則直接返回。

注意：1.補丁dex可以通過app內部動態部署下載到指定目錄

2.修復完成或者移除補丁，需要重啟app才可生效

3.該方案只是為大概原理，具體商業化使用遠遠不夠。

4.除了以上說的，還有另外的方案。比如動態修改字節碼文件。（未學習，不做討論）

5.熱更新是不需要預留插槽的，因為主要是為了修復已有的功能，縫補已有bug的同名文件。