為什麼要元件化？

在這之前我們先看一個圖，摘自我的腦圖：

所以，一直是需求再推動著我們前進，還有萬惡的產品！！！

目前的主流方案：主工程多子工程開發模型

所有業務元件不再是mouble而是作為一個子工程,基礎元件可以使moudle,也可以是子工程,該子工程和主工程不同:
Debug模式下下作為app,可以單獨的開發,執行,除錯;Release模式下作為Library,被主工程所依賴,向主工程提供服務.

貼一個通用的圖：

當然也有這個圖的進階版：為了解決依賴和公共資源，把Common Library移動到Router上面。
這個看需使用吧。具體的可以看我的腦圖

多子專案的配置

if (isDebug.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}
在android {}裡：
sourceSets{
        main(){
            if(isDebug.toBoolean()) {
                manifest.srcFile 'src/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/release/AndroidManifest.xml'
            }
        }
    }
 

下面的在APP的gradle的也注意加上，不然在子專案作為application的時候，編譯過不去

if (!isDebug.toBoolean()) {
        implementation project(':buylibrary')
    }

有時候當你都配置完了，發現還是編譯不過去：

No signature of method: static org.gradle.api.java.archives.Manifest.srcFile

這是你細心點就會發現，這裡的報錯資訊跟上面配置的manifest有關，你再細心點會發現首字母大小寫也有關。。。如果有錯，就用大寫。其實有的專案裡用的大寫也沒錯，不知道是什麼鬼？反正這麼做就對了！！！

資源衝突：

子專案中新增：resourcePrefix "你的別名"
這樣的話，如果你的子專案中的資源沒有在前面加別名，編譯就過不去，挨個修改就行了。
但是這個不會限制圖片資源，所以才有上面說的進階版：為了解決依賴和公共資源，
把Common Library移動到Router上面。所以，把公共資源放到這裡把。

重複依賴

倆個方案：

1. 跟資源衝突的解決方案一樣，把公共依賴放到Common Library中
2. 限制依賴修飾符

解決 Application 衝突

public class App {
    public static final Application INSTANCE;

    static {
        Application app = null;
        try {
            app = (Application) Class.forName("android.app.AppGlobals").getMethod("getInitialApplication").invoke(null);
            if (app == null)
                throw new IllegalStateException("Static initialization of Applications must be on main thread.");
        } catch (final Exception e) {
            LogUtils.e("Failed to get current application from AppGlobals." + e.getMessage());
            try {
                app = (Application) Class.forName("android.app.ActivityThread").getMethod("currentApplication").invoke(null);
            } catch (final Exception ex) {
                LogUtils.e("Failed to get current application from ActivityThread." + e.getMessage());
            }
        } finally {
            INSTANCE = app;
        }
    }
}
 

元件間通訊

這裡引入了一個路由（Router）的概念：引入匯流排機制來解決裝置掛載問題,同樣,借用匯流排的概念我們在工程新增”元件匯流排”,用於不同元件間的通訊。
也有用隱式跳轉的，這裡不推薦，一是不安全，二是麻煩。

目前主流的方案就是註解，代表是阿里的ARouter。如果你的量級比較小，比如說沒有複雜的services等等吧，可以自定義註解，不然推薦阿里的方案，沒有侵入式程式碼，使用還方便。
這裡也推薦一下別人寫的庫：
ARetrofit
ActivityRouter

其實，元件化的方式並不複雜，複雜的是根據自己的專案如何做到業務的解耦，這個是沒人能給你講的，我們只能吸收前人的經驗，然後儘量把程式碼寫的好一點。