——》個人平時筆記，看到的同學歡迎指正錯誤，文中多處摘錄于各大博主精華、書籍
1、首先組件和模塊都不是官方規定的，都是這些技術發展下來大家約定俗成的概念，他們都是一個個Module，只是概念內容不一樣而已。
Module包含兩種格式: application， library。一個Module就是一個小的項目，Module通過依賴來注入到主app工程中，也是AS概念中的模塊。
>1.模塊化開發：按照項目業務模塊來劃分，將一個app按業務拆分為登錄模塊、聊天模塊等等，模塊化其中一個核心的目的就是代碼的高可復用、高可維護和高可擴展性能。
模塊化的概念可以說貫穿整個組件化、插件化。
>2.組件化開發：對應用功能的封裝，一個功能一個組件。比如網絡連接交互組件、即時通訊IM組件、數據庫組件等。是對模塊化更小的細分。
正常一個app中可以有多個module，但是一般只會有一個module是設置為application的，其他均設置為library。將一個工程分成各個模塊，各個模塊之間相互解耦，可以將module均設置為application獨立開發并編譯成一個獨立的 app進行調試，然后又可以將各個模塊module均設置為library組合起來整體構成一個完整的 app，這個概念和模塊化沒有本質的界限。
組件可以分為兩大類，一類是application組件，一類是libs組件，application組件是一個可運行的app。library組件可以作為application的依賴，但是自身不可作為程序運行的存在。只有Module類型為application的組件才能單獨提出來做為程序運行存在。
組件化是建立在模塊化思想上的一次演進，一個變種。組件化本來就是模塊化的概念，但是組件具有可以在模塊和單獨運行的apk之間自由設置切換的特性。即組件化的核心是模塊角色的可轉換性， 在打包時是library，在調試時是application。
組件只是我們在代碼開發階段中為了方便叫的一個術語，在組件被打包進APP的時候是沒有這個概念的，這些組件最后都會被打包成arr包，然后被app殼工程所依賴，在構建APP的過程中Gradle會自動將重復的arr包排除，APP中也就不會存在相同的代碼了。
解決以下項目中的問題：
1.稍微改動一個模塊的一點代碼都要編譯整個工程，耗時耗力
2.公共資源、業務、模塊混在一起耦合度太高
3.不方便測試
2.插件化開發
宿主是指普通的apk，插件一般是指經過處理的dex或者apk，在主流的插件化框架中多采用經過特殊處理的apk來作為插件，處理方式往往和編譯以及打包環節有關。Android應用程序的.java文件在編譯期會通過javac命令編譯成.class文件，最后再把所有的.class文件編譯成.dex文件放在.apk包里面。那么動態加載（插件化）就是在運行時把插件apk直接加載到classloader里面的技術。
目的：插件化就是要減小宿主程序apk包的大小，同時降低宿主程序的更新頻率并做到自由裝載模塊、在線更新模塊。
好處：
1.宿主和插件分開編譯
2.并發開發
3.動態更新插件
4.按需下載模塊
5.方法數或變量數爆棚
總結：
插件化和組件化沒有可比擬性，組件化通俗點講就是一個項目結構設計、架構思路，而插件化是一個新興技術的應用。組件化在打包編譯前按需加入功能模塊，插件化在打包完成主apk后將新需要的功能模塊單獨打包成apk文件插入主apk中。即組件化的單位是組件（module）。插件化的單位是apk(一個完整的應用)。
①組件化：
1. 用于項目過大，每次編譯時間長
2. 用于團隊多個人分工開發不同的模塊
3. 更好的解耦
4.組件化的靈活性在于按加載時機切換，分離出獨立的業務功能組件，比如微信的朋友圈
②插件化：
1. 用于版本新添加功能，更多的是啟動另一個apk中的activity，或使用另一個apk的資源
2. 解決方法數超過65536問題
3. 按照需要下載模塊，減小項目apk的大小
4.本質上它使用的技術還是熱修復技術
5.插件化的靈活性在于是加載apk, 完全可以動態下載，動態更新，比組件化更靈活
③熱更新（熱修復）：可以使用第三方的框架，現在都已經很成熟了如：騰訊提供的Bugly
1. 用于修復已經上線的bug等問題
2. 一般不用于新功能的版本上線
3.強調的是修改線上版本的bug，用技術去實現不更新整個apk的條件下，修改掉bug
熱更新兩種方式：
>>1.阿里系：DeXposed、andfix：從底層二進制入手（c語言）。
>>2.騰訊系：tinker：從java加載機制入手。通過類加載器加載這些修復好的class，覆蓋對應有問題的class，理論上就能修復bug了。
Android平臺出現了一些優秀的熱更新方案，主要可以分為兩類：一類是基于multidex的熱更新框架，包括Nuwa、Tinker等；另一類就是native hook方案，如阿里開源的Andfix和Dexposed。這樣客戶端也有了實時修復線上問題的可能。但經過調研之后，我們發現上述方案或多或少都有一些問題，基于native hook的方案：需要針對dalvik虛擬機和art虛擬機做適配，需要考慮指令集的兼容問題，需要native代碼支持，兼容性上會有一定的影響；基于Multidex的方案，需要反射更改DexElements，改變Dex的加載順序，這使得patch需要在下次啟動時才能生效，實時性就受到了影響，同時這種方案在android N [speed-profile]編譯模式下可能會有問題。
總結：插件化和熱更新雖然都是軟件開發中的重要技術，但它們是不同的概念。插件化是一種軟件設計架構，用于實現軟件的動態擴展和模塊化；而熱更新則是一種在軟件運行時動態替換代碼或資源的技術，用于提高軟件的穩定性和用戶體驗。插件化更側重于通過添加新的功能模塊來擴展軟件的功能，而熱更新則側重于在不重啟軟件的情況下替換或更新現有的代碼或資源。
3、組件化的混淆規則：
各個業務組件的混淆配置規則都應該在app殼工程中的混淆配置文件中添加和修改。之所以不采用在每個業務組件中開啟混淆的方案，是因為 組件在集成模式下都被 Gradle 構建成了 release 類型的arr包，一旦業務組件的代碼被混淆，而這時候代碼中又出現了bug，將很難根據日志找出導致bug的原因；另外每個業務組件中都保留一份混淆配置文件非常不便于修改和管理，這也是不推薦在業務組件的 build.gradle 文件中配置 buildTypes （構建類型）的原因。
