控制反轉，依賴注入：

耦合結構和解耦結構

目前我的專案的結構如下圖所示，因為intent跳轉和一些資料共享的關係導致的。

解耦合之後的結構：

解耦思想

控制反轉是一種思想

依賴注入是一種設計模式

IoC框架使用依賴注入作為實現控制反轉的方式

模組化開發

將一個程式按照其功能做拆分，分成相互獨立的模組，以便於每個模組只包含與其功能相關的內容。模組我們相對熟悉,比如登入功能可以是一個模組,搜尋功能可以是一個模組,汽車的傳送機也可是一個模組。

元件式開發

基於可重用的目的，將一個大的軟體系統按照分離關注點的形式，拆分成多個獨立的元件，已較少耦合。

將一個app分成多個模組，每個模組都是一個元件（Module），開發的過程中我們可以讓這些元件相互依賴或者單獨除錯部分元件等，但是最終釋出的時候是將這些元件合併統一成一個apk，這就是元件化開發。

正常一個App中可以有多個module，但是一般只會有一個module是設定為application的，其他均設定為library，元件化開發就是要每個module都可以執行起來，因此在開發期間(Debug版本)每個module均設定為application，釋出時(Release版本)設定為libs再進行合併。

元件可以分為兩大類，一類是application元件，一類是libs元件，application元件是一個可執行的app。libs元件可以作為application的依賴，但是自身不可作為程式執行的存在。

模組化粒度更小,更側重於重用,而元件化粒度稍大於模組,更側重於業務解耦。

元件化想要解決的問題：

1.       實際業務變化非常快,但是工程之前的業務模組耦合度太高,牽一髮而動全身.

2.       對工程所做的任何修改都必須要編譯整個工程

3.       功能測試和系統測試每次都要進行.

4.       團隊協同開發存在較多的衝突.不得不花費更多的時間去溝通和協調,並且在開發過程中,任何一位成員沒辦法專注於自己的功能點,影響開發效率.

5.       不能靈活的對工程進行配置和組裝.比如今天產品經理說加上這個功能,明天又說去掉,後天在加上.

元件開發比較常見的問題是業務元件的相互引用：

為此我們可以通過路由/匯流排的方式去處理：

掛載到元件總線上的業務元件,都可以實現雙向通訊.而通訊協議和HTTP通訊協議類似,即基於URL的方式進行.

外掛化開發

Android應用程式的.Java檔案在編譯期會通過javac命令編譯成.class檔案，最後再把所有的.class檔案編譯成.dex檔案放在.apk包裡面。那麼動態載入就是在執行時把外掛apk直接載入到classloader裡面的技術。

關於程式碼載入，系統提供了DexClassLoader來載入外掛程式碼。開發者可以對每一個外掛分配一個DexClassLoader(這是目前最常見的一種方式)，也可以動態得把外掛載入到當前執行環境的classloader中。

相對於元件化開發主要要解決的問題：

1.       宿主和外掛分開編譯

2.       併發開發

3.       動態更新外掛

4.       按需下載模組

5.       方法數或變數數爆棚

元件化的核心是角色的轉換。 在打包時， 是library; 在除錯時， 是application。

怎麼理解元件化的概念 ？

Module的模式分兩種， application和library。 library就是引用庫，如你抽取的common。 application就是一個apk， 是一個完整的專案。

在除錯時，我只關心我負責的模組，我希望我的模組是一個單獨的app,因為這樣更小，業務更專一，相對來講修改與除錯就會越省時省心，編譯就會越快。試想當你需要改一段程式碼，既要關注自己的，也要關注別人的，是一種什麼體驗 ？ 或者， 編譯一個專案10M的程式碼和一個工程全部1G的程式碼，哪個比較舒服一些？

外掛化

又有人問了： 外掛化和元件化又有什麼區別呢？外掛化嚴格意義來講，其實也算是模組化的觀念。將一個完整的工程，按業務劃分為不同的外掛，都是分治法的一種體現。化整為零，相互配合。，越小的模組越容易維護。 外掛化按理也算是模組化的一種體現，和元件化就不一個概念了。那麼，到底有什麼區別呢？

元件化的單位是元件（module）。
外掛化的單位是apk(一個完整的應用)。
元件化實現的是解耦與加快編譯， 隔離不需要關注的部分。
外掛化實現的也是解耦與加快編譯，同時實現熱插拔也就是熱更新。
元件化的靈活性在於按載入時機切換，分離出獨立的業務元件，比如微信的朋友圈
外掛化的靈活性在於是載入apk, 完全可以動態下載，動態更新，比元件化更靈活。
元件化能做的只是， 朋友圈已經有了，我想單獨除錯，維護，和別人不耦合。但是和整個專案還是有關聯的。
外掛化可以說朋友圈就是一個app, 我需要整合了，把它整合進微信這個大的app裡面
其實從框架名稱就可以看出： 組 和 插。
組本來就是一個系統，你把微信分為朋友圈，聊天， 通訊錄按意義上劃為獨立模組，但並不是真正意義上的獨立模組。
插本來就是不同的apk， 你把微信的朋友圈，聊天，通訊錄單獨做一個完全獨立的app, 需要微信的時候插在一起，就是一個大型的app了。
外掛化的載入是動態的，這點很重要，也是靈活的根源。

通訊方式

模組化的通訊方式，無非是相互引入；我抽取了common, 其他模組使用自然要引入這個module
元件化的通訊方式，按理說可以劃分為多種，主流的是隱式和路由。隱式的存在使解耦與靈活大大降低，因此路由是主流
外掛化的通訊方式，不同外掛本身就是不同的程序了。因此通訊方式偏向於Binder機制類似的程序間通訊