1 .組件間的application合并規(guī)則

1. 功能module有自定義Application,主module沒有自定義Application,打包會引用功能模塊module的自定義Application
2. 主module有自定義Application ,其他module沒有，則打包的時引入主module的Application
3. 功能module有多個Appcation,每個module 添加 tool:replace = "android:name"，會打包最后編譯module的Application
4. 主module有自定義Application,其他功能module也有自定義Application，在主module 中添加replace = "android:name"
   ，打包編譯是主module 的Application

2. 組件間的通信

本地廣播

優(yōu)點

1. 只在app內(nèi)廣播
2. 比全局更加高效

缺點

使用繁瑣

EventBus

優(yōu)點

1. 簡化組件間通信方式
2. 實現(xiàn)解耦
3. 動態(tài)設(shè)置事件處理線程和優(yōu)先級

缺點
每個事件都定義一個事件類，造成事件類太多，維護成本增加

3. 組件間的跳轉(zhuǎn)

ARouter

優(yōu)點

1. 組件跳轉(zhuǎn)
2. 自定義攔截器
3. 提供Ioc容器
4. 降級策略

4. 相互調(diào)用

由于主項目與組件，組件與組件之間都是不可以直接使用類的相互引用來進行數(shù)據(jù)傳遞的，那么在開發(fā)過程中如果有組件間的數(shù)據(jù)傳遞時應(yīng)該如何解決呢，這里我們可以采用 [接口 + 實現(xiàn)] 的方式來解決。

在這里可以添加一個 ComponentBase 模塊，這個模塊被所有的組件依賴，在這個模塊中分別添加定義了組件可以對外提供訪問自身數(shù)據(jù)的抽象方法的 Service。ComponentBase 中還提供了一個 ServiceFactory，每個組件中都要提供一個類實現(xiàn)自己對應(yīng)的 Service 中的抽象方法。在組件加載后，需要創(chuàng)建一個實現(xiàn)類的對象，然后將實現(xiàn)了 Service 的類的對象添加到 ServiceFactory 中。這樣在不同組件交互時就可以通過 ServiceFactory 獲取想要調(diào)用的組件的接口實現(xiàn)，然后調(diào)用其中的特定方法就可以實現(xiàn)組件間的數(shù)據(jù)傳遞與方法調(diào)用。

當然，ServiceFactory 中也會提供所有的 Service 的空實現(xiàn)，在組件單獨調(diào)試或部分集成調(diào)試時避免出現(xiàn)由于實現(xiàn)類對象為空引起的空指針異常。

5. 組件初始化

Base module定義接口BaseAppInit

public interface BaseAppInit{
    void onInit(Application app)
}

其他module實現(xiàn)BaseAppInit

public class ModuleA implements BaseInit{
    public void onInit(Application app){
        //執(zhí)行初始化操作
    }
}

在主module Application 里面執(zhí)行初始化
通過反射，初始化各個組件的 Application。

6. 組件化資源

依賴包沖突

gradle 打包時默認使用版本比較高的依賴

如果想使用比較低的版本，使用exclude排除依賴

資源名沖突

如果有字段名一樣的，后編譯的模塊會覆蓋之前編譯的內(nèi)容

1. 命名規(guī)范
2. gradle 添加 resourcePrefix字段