單一工程
顧名思義，就是一個代碼工程(Project)對應一個APP了，這個APP的所有業務功能都是集中在同一個工程裏實現的。
組件化
簡單來說，就是將一個APP的業務功能進行拆分，每一個功能都是一個單獨的工程（Module），每個工程都能獨立運行，且只包含自己的業務，我們姑且叫這個獨立的功能爲一個組件服務，最後由一個空殼APP將多個拆分出的組件集成而成。
單一工程
優點
**
- 適合人數較少(1-3)，較小項目
- 寫起代碼來比較行雲流水，反正我基本哪裏都能訪問到…
**
缺點
**
- 對工程的任意修改，都要編譯整個工程，效率十分低下；
- 不利於多人團隊協同開發，別人改了一個地方影響到了你瞭解一下，合併代碼瞭解一下…
- 無法做到功能複用，例如要做客製化…
- 業務模塊耦合嚴重，時間長了很可能會你中有我，我中有你，修改一個業務可能會牽一髮而動全身，不利於後期迭代與維護。
**
組件化工程
優點
**
- 極大提高了編譯速度，只需要編譯當前的模塊；
- 業務模塊解耦，有利於多人協同開發，彼此互不打擾，模塊代碼質量只會侷限於自身模塊內；
- 組件化是功能重用的基石；
- 模塊之間互相不依賴，就沒有耦合。
**
缺點
**
- 前期需要花費更多的時間來模塊劃分；
- 一個人的小項目沒有必要組件化，會帶來更多的工作量；
- 組件化需要良好的架構設計，需要高水平的架構師統籌全局，經驗不足的同學盲目進行組件化可能會適得其反。
**
組件化需要解決的幾個問題：
- 如何分成各個模塊？
- 各個模塊之間如何進行數據共享和數據通信？
- 如何將各個模塊打包成一個獨立的 APP 進行調試？
- 如何防止資源名稱衝突？
- 如何解決 library 重複依賴以及 sdk 和依賴的第三方版本號控制問題？
解決方案：
- 根據業務進行拆分，拆分出來的模塊不要過多，會增加維護的難度。
- 我們可以把需要共享的數據劃分成一個單獨的模塊來放置公共數據。各個模塊之間的數據通信，我們可以使用阿里的 ARouter 進行頁面的跳轉，使用封裝之後的 RxJava 作爲 EventBus 進行全局的數據通信。
- 我們可以在各個模塊的 gradle 文件裏面配置需要加載的 AndroidManifest.xml 文件，並可以爲每個應用配置一個獨立的 Application 和啓動類。
- 遵守命名規約就能規避資源名衝突問題。
- 可以將各個模塊公用的依賴的版本配置到 settings.gradle 裏面，並且可以建立一個公共的模塊來配置所需要的各種依賴。