android發展到今天，雖然說很多的業務邏輯都會放在服務端處理，但是隨著功能的增加，app的體積還是會越來越大，雖然統一採用了規定的MVP模式，有時候還是連自己都覺得各個模組間的相互依賴太多，比如說我們有訂單模組，購物車模組，門店模組，個人中心模組等等，相互之間都會有依賴。
以前我們的模組是這樣的：

上面這個圖是做過androd的程式設計師最熟悉不過的工程了，所有的java檔案都寫在同一個app模組下。
那麼下面我們再來看下現在的工程（只是一個列子）

上面劃掉的也是一個模組，只是由於公司的名稱的原因，所以不方便展示（以下模組劃分只是一個參考）。

那當初為什麼這個劃分呢？
1：首先由於功能模組很多，一下子劃分為很多的模組，任務量會比較大， 所以我們的原則是當要在模組模組中修改需求時，根據模組的歸屬，我們會把它抽取成一個module，這樣就可以在增加業務的同時進行元件化工作，同時減少測試同學的工作量。
2：每一個模組，只需要能夠實現一個功能，比如門店模組，裡面所有的實現都是有關門店有關的程式碼。
3：跳轉，當改動其他模組的時候，跳轉的邏輯能夠不需要修改。雖然現在分的模組不是很細，但如果到時侯某個模組需要分解成更小的不同的模組的時候，跳轉也不需要變化。
4：每個模組由於存在於不同的git倉庫中，所以打包apk的時候，我們只要通過依賴響應的aar，就能夠實現。
5：修改底層庫，比如網路層，相簿層，因為我們提供了介面，所以底層的修改不會引起業務邏輯層的修改。
在元件化的工程中遇到的問題：
1：通用物件在各個模組間的使用
公共的物件，由於在不同的模組中需要使用中，所以我們暫時先把他放在了基礎元件的地方。
2：跨 module 的 Activity 或 Fragment 跳轉問題
跳轉，通過統一的介面的跳轉邏輯實現。
3：AAR 或 library project 重複依賴

以上的元件化過程還有很長的路要走，僅記下，為以後更好的元件化。