Android：模組化 or 元件化
模組化
模組化程式設計是將一個程式按照功能拆分成相互獨立的若干模組，它強調將程式的功能分離成獨立的、可替換的模組。每個模組內只有與其相關功能的內容。
模組化程式設計和結構化程式設計與面向物件程式設計是密切相關的，它們的目的都是將大型軟體程式劃分成一個個更小的部分。模組化程式設計的粒度會更“粗”一些。在Java9中也在編譯器層面提供了模組化的支援：Java Platform Module System 。
元件是一個類似的概念，但通常指更高的級別；元件是整個系統的一部分，而模組是單個程式的一部分。“模組”一詞因語言而有很大差異；在Python中，它非常小，每個檔案都是一個模組，而在Java 9中，它是非常大的，其中模組是包的集合，包又是檔案的集合。
在面向物件程式設計中，通常使用介面作為模組間通訊的橋樑，也就是基於介面的程式設計。
元件化
元件化開發是軟體工程的一個分支，它強調對給定軟體系統中廣泛可用的功能進行分割。基於可重用的目的將一個大的軟體系統拆分成多個獨立的元件，減少系統耦合度。
元件化開發中認為元件作為系統的一部分，是可獨立執行的服務，維基百科中舉了一個例子：在web服務中，有一種面向服務的架構設計--service-oriented architectures (SOA)，這種架構設計從業務角度出發，利用企業現有的各種軟體體系，重新整合並構建起一套新的軟體架構。這套軟體架構可以隨著業務的變化，隨時靈活地結合現有服務，組成一個新的軟體。增加應用系統的靈活性。
元件可以產生或者消費事件，也可以應用於事件驅動架構。
元件之間通過介面進行通訊
元件是可替換的，如果後續元件滿足初始元件的需求（通過介面表示），則元件可以替換另一個元件（在設計時或執行時），因此可以用更新的版本或替代的版本替換元件，而不會破壞系統的執行。
一個判斷可替換元件的經驗法則是：如果元件B至少提供了A提供的元件，並且使用的元件不超過A使用的元件，那麼元件B可以立即替換元件A
當元件直接與使用者互動時，應該考慮基於元件的可用性測試。
元件需要是完全文件化、全面測試、具有全面的輸入效度檢查的。
模組化 or 元件化
不管是模組化還是元件化，都不是一個新的設計思想，它們最早都是在20世紀60年代就已經被提出了，但是早期的移動應用由於相對簡單，本身邏輯功能也不多，所以在移動端的應用反而沒那麼廣泛。（雖然Java最開始的模組化是針對在移動和嵌入式裝置上的應用設計的）。
從上面的概述來看其實元件化跟模組化沒有明顯的區別；一個登入功能可以是一個模組也可以是一個元件，一個日期選擇控制元件可以是一個模組，也可以是一個元件，因為不管是模組化還是元件化，它們都有一個共同的目標：將一個大的軟體系統細化成一個個模組或者元件，都是為了重用和解耦。因此沒有一個明確的界線去區分它們。
網上很多文章對於元件和模組的定義也是不盡相同的，一些人認為元件的粒度更細，它只是具備單一功能與業務無關的元件，比如一個日曆選擇控制元件就認為是一個元件。而模組他們認為就是業務模組，顧名思義，就是按業務劃分而成的模組。而另一部分人則相反。
在維基百科對模組化的解釋中有這麼一句：
A component is a similar concept, but typically refers to a higher level; a component is a piece of a whole system, while a module is a piece of an individual program
也就是認為元件粒度較模組要更大，所以本文對元件和模組做出以下定義：
元件 ：側重於業務，可編譯成單獨的app，一般只負責單一業務，具備自身的生命週期（通常包含Android四大元件的一個或多個，所以稱之為元件也更加貼切）
模組 ：側重於功能，與業務無關，比如自定義控制元件、網路請求庫、圖片載入庫等
而從Android Studio推出之後，我們在開發專案時也會有意識的將一些可重用的程式碼邏輯抽離成一個個的Module，這也就是模組化開發的雛形。當然，元件化開發也不是就盡善盡美的，下面列舉了它的一些優缺點：
優點 ：一個複雜的系統可以由一個個元件集合而成，甚至於不同的組合可以構建出不同的系統。每個元件有獨立的版本，可獨立編譯、打包，大大提高了系統的靈活性以及開發人員的開發效率。應用的更新可以精細到元件，元件的升級替換不會影響到其它元件，也不會受其它元件的限制。
基於元件化架構設計的應用比傳統的“單片”設計可重用性高得多，因為這些元件可以在其他專案中重用，而且開發人員無需瞭解整個應用，可以只專注於分配給他們的較小的任務，提高開發效率。
缺點 ：元件化的實施對開發人員和團隊管理人員提出了更高水平的要求，專案管理難度更大。元件間如何進行通訊也是需要慎重考慮的。萬事開頭難，在對一個專案進行元件化分解時就好像庖丁解牛一般，你需要了解專案的“肌理筋骨”，才知道從何處下“刀”，才能更輕易的去分解專案，這就要求架構師對於專案的整體需求瞭如指掌。
附：元件化學習資料以及視訊
元件化學習體系
視訊 ：加群 “ 4112676 ”驗證： 視訊 免費領取
Android視訊資料