隨着業務的發展和技術的變更，Android開發也經歷了以下幾個發展階段：
看似高大上的名詞，其實遵循着最簡單的原則：分而治之（如何劃分就是“架構”，簡單的事情如何串在一起就是“接口協議”，CS領域太多這樣的例子了。）
我的理解是，模塊化/組件化/插件化都是一種廣義的模塊化，只是它們的實現方式不同而已。
模塊化系統案例：
- 智能android設備：Launcher, Lock Screen, Live Wallpaper,AppStore,BatteryManager
- Hadoop生態系統：HDFS,YARN,MapReduce等
單體應用
業務代碼 + 數據存儲 + 接口請求 + 日誌 等各個模塊雜糅在一個module中。
這種結構基本上已經不適用任何項目，只能作爲個人的測試或者demo。
優點：
- 編譯構建簡單
缺點：
- 無法適用與複雜的業務結構
廣義的模塊化
“Modular hardware lead to modular software”
模塊化特點：
- 模塊間耦合小（模塊間一般通過接口進行通信/調用）
- 模塊可替換(接口不變底層實現可替換)
模塊化代價：
- 模塊間調用複雜
- 需要擬定接口協議
- 兼容性問題（不同的module可能依賴不同的版本）
爲什麼需要模塊化：
- 實現高內聚低耦合的代碼
- 不同module可以並行開發和測試
- 靈活的集成/部署/升級
模塊化的方式：
- 分包
- Android studio中分module
- 應用拆分（一個應用拆分成多個應用）
俠義的模塊話
android開發時，狹義的模塊話就是在project中建立多個module。比如將數據庫的處理建立一個module，業務代碼建立一個module（業務很複雜的化也可以根據業務場景進行拆分），日誌埋點作爲一個module等
組件化
組件化是在狹義模塊化思想上的一次演進，一個變種。
組件化的核心是角色的轉換。 在打包時， 是library; 在調試時， 是application。
A在開發測試業務1時就可以把“業務1”作爲一個Application，進行構建測試。 當需要構建整個App時，“業務1”又是一個library，構建腳本就能控制這一切。
看似很簡單，但是業務場景千奇百怪，還有很多問題需要解決：
- 業務模塊之間的通信： 如果時統一進程直接定義接口即可，跨進程可考慮使用AIDL
- Main Activity入口問題： 腳本控制使用不同的AndroidManifest文件
- activity跳轉問題：
插件化
待補充
實例： 微信客戶端架構演進
參考：https://www.infoq.cn/article/wechat-android-app-architecture/