組件化項目實戰

概述

組件化緣由

記得剛開始接觸Android開發的時候,只知道MVC分層架構,而且感覺Model,View以及Controller太簡單了,也能稱之為分層架構,隨便寫就是MVC。就像在接觸設計模式之前,你可能已經寫了無數個單例模式,只是那個時候你可能并不知道,你已經在用設計模式了,你不會去想是用DCL還是使用內部類實現的單例優雅。

后來當一個類中的代碼上千行之后,就開始想著抽取公共方法作為工具類,使用封裝、繼承以及多態來優化自己的代碼,直到隨著業務的發展,在View層的邏輯越來越多,無法抽取時,發現MVC的天花板其實很低,Activity跟Fragment作為View層經常會跟Model層糾纏不清,及時進行抽取之后,也還是很臃腫。MVP的出現,徹底解決了這個問題,解耦Model層跟View層,使得整個項目的代碼顯得更加簡潔。

在項目初期的的時候,感覺MVP還是很不錯的,當項目逐漸變大的時候,每次你改動了很小的一部分,你也需要重新編譯整個APP,舉個例子,就拿購物車來說,我修改了數量比狂的樣式,我需要重新編譯整個APP,為了加快速度,我可能要開啟InstantRun,可能要使用Freeline來加速編譯,這并不是我想要的,而且在使用InstantRun之后,output目錄下生成的apk是差量包,只能供開發調試,給測試是無法安裝的,我要是想通過腳本上傳到fir給測試人員,那又得打一個全量的包,并且InstantRun也不是很穩定。

組件化效果

毫無懸念,組件化勢在必行,在網上看了很多相關的資料,對組件化有一個初步的了解,然后就開始組件化了,下面1以我自己的項目為例,放兩張組件化之前跟之后的圖對比一下。

image

可以明顯的發現我們的Module變多了,就像MVC切換到MVP之后,需要寫很多的Presenter組件化最大的好處就是可以模塊可以單獨開發調試,這樣效率一下子就上來了,還是拿購物車舉例,購物車實際上就只有一個界面,也就是一個Fragment,加上啟動頁跟Fragment的父Activity,也就兩個界面,可以說想慢都慢不下來,下面就我在組件化過程中遇到的一些問題進行總結一下。

正文

指導思想

組件拆分

組件化的目的在于將一個project劃分成業務組件、基礎組件、路由組件。其中業務組件是相互隔離的,可以單獨調試,基礎組件提供業務組件所公用的功能,路由組件為業務組件之間通信提供支持。

一般來講,一個APP可以由一個app殼,然后集成多個Module,這是理想的情況,但是從運營的需求到產品的設計到UI出圖,可能你就會對組件化很絕望,并不是那么的理想,很多時候我們程序入口所在的Module實際上跟其它很多Module是關聯的,實際上沒法拆分,本文將會以這種比較復雜的情況進行組件化分析。

組件隔離

組件化的一個很大的特性在于可以單獨調試,但是由于業務組件之間的隔離,所以導致了多個組件之間無法進行通信,其實我覺得是很正常的,既然是單獨調試,就必然不應該跟其它的Module間進行依賴,不管是編譯期還是運行期都應如此,不然組件化就沒有任何意義了,但是由于我們的業務組件都是相互關聯的,如果不依賴其他的組件的話,作為一個單獨的APP運行有時候是需要參數的,鑒于此,我們可以在Application初始化的時候,新增一個頁面作為參數配置,或者直接在Application中固定寫死。

核心法則

不管我們如何劃分,如何依賴,組件間的關系都要嚴格遵守一個準則:編譯器隔離,運行期按需依賴

整體架構

image

通過組件化將項目按照業務進行化分成GoodsModuleCartModuleUserModuleOrderModule四個模塊,模塊間通過RouterModule進行通信,也就是說業務組件依賴于路由組件,RouterModule依賴于Base,也就是BaseModuleLibraryModule,基礎庫跟第三方庫,然后MainModule實際上相當于程序的入口跟容器,通過MainModule依賴上述四個Module,完成整個APP的打包。

當然在單獨調試的時候,GoodsModuleCartModuleUserModuleOrderModule又各自成為一個APP,可以單獨進行調試,這樣就實現了APP的組件化,下面就組件化過程中遇到的一些問題總結一下。

組件化分析

在組件化的過程中,由于Module之間是隔離的,所以就產生了一系?列問題,現在就組件化前后的遇到的問題總結如下:

  • 組件劃分:如何根據業務對項目進行Module劃分
  • 模式切換:如何使得APP在單獨調試跟整體調試自由切換
  • 資源沖突:當我們創建了多個Module的時候,如何解決相同資源文件名合并的沖突
  • 依賴關系:多個Module之間如何引用一些共同的library以及工具類
  • 組件通信:組件化之后,Module之間是相互隔離的,如何進行UI跳轉以及方法調用
  • 入口參數:我們知道組件之間是有聯系的,所以在單獨調試的時候如何拿到其它的Module傳遞過來的參數

接下來會根據?這幾個問題,提出對應的解決方法

組件劃分

業務劃分

由于我們做的是一個電商項目,網上也查找了很多資料,感覺他們舉的例子都有些過于簡單,因為模塊間基本上沒有什么耦合,所以很好拆分,不過還是很感謝他們提供了一種解決思路。玩過京東,淘寶都知道,大致分為幾個大的模塊:商品模塊,購物車模塊,訂單模塊,用戶模塊。沒錯,我也是這么拆分我們APP的。但是拆著拆著就發現問題了,模塊間耦合性太高,我們過了SplashActivity之后就是MainActivity,看圖說話

image

所以網上的一些一進來就是一個空的APP殼的方法并不適用,從一開始就遇到了這個棘手的問題,有點尷尬,按照之前的模塊劃分,在用戶登陸的情況下MainModule一進來就必須拿到GoodsModuleCartModule以及UserModule中的三個Fragment。所以首先必須得解決這個問題,很顯然之前的使用一個APP殼來合并多個Module的情況并不適用,起初我直接定義了一個MainModule,然后讓他直接引用多個Module,那么MainModule就承擔了APP殼的功能,這樣一來,就可以解決MainModule對其它Module的引用問題,但是違背了組件化的業務組件隔離的原則。

所以不能讓MainModule依賴另外三個Module,但是如果我不引用其他的Module,那么很顯然我無法拿到這四個Fragment的引用,有一點可以很明確,那就是編譯期業務Module之間必須不可見,這點是毫無疑問的。但是運行期是可見的,因為所有的Module在運行期間肯定都是通過直接或者間接依賴,不然有些Module就沒用了,在運行時獲取實例,那么很自然地就會想到反射了,沒錯就是反射。

依賴劃分

除了業務模塊之外,我們還會有一些公用的工具類以及資源文件,也就是Base類,比如說多個Module共同使用的資源文件,我們都可以放在一個Module里面,另外就是還有第三方依賴,這里我新建了兩個Module一個是BaseModule,一個是LibraryModule。整體關系如下

業務組件——>路由組件——>基礎組件

模式切換

定義開關

切換的時候需要一個開關,來表示是單個Module間運行還是多個Module間運行,很容易想到是一個布boolean類型的標志,可能你也想到了,在gradle.properties中來定義,網上好像都是這么做的,實際上我們還可以在BaseModule以及LibraryModule定義,原因很簡單,只需要所有的Module中都能夠訪問就行了,只要遵循這個原則都是OK的,只是在gradle.properties中定義跟使用都比較方便。

isDebug=false//Debug還是Release
isModuleRun=true//是否單Module運行

這里我不僅僅定義了isModuleRun,還定義了isDebug,是不是感覺有些奇怪,不是可以通過BuildConfig.Debug來判斷當前是否是Debug模式么,因為我們的url配置信息都是寫在BaseModule中以便于所有的Module調用,他是一個Library,關于Library這里還有一個問題注意下,由于Library的Module打包方式是使用release模式打包的,所以BuildConfig.Debug永遠是false,所以我們需要額外定義一個變量isDebug,然后手動在Debug跟Release中進行切換,然后在BaseModule的gradle中進行判斷

if (isDebug.toBoolean()) {
    //debug模式
    buildConfigField "String", "AlphaUrl", "\"${url["debug"]}\""

} else {
    //release模式
    buildConfigField "String", "AlphaUrl", "\"${url["release"]}\""

}

使用開關
Application

isModuleRun為false的時候,Application跟AndroidManifest都是以Library的形式參與編譯,不需要啟動的Activity以及自定義的Application反之則需要。

isModuleRun=false

無序修改

<application
    android:allowBackup="true"
    android:supportsRtl="true"
    android:theme="@style/AppTheme">
 </application>

isModuleRun=false

在main/debug目錄下新建一個AndroidManifest.xml文件

<application
    android:name=".debug.GoodsApplication"
    android:allowBackup="true"
    android:label="@string/goods_name"
    android:supportsRtl="true"
    tools:replace="android:label"
    android:theme="@style/AppTheme">
    <activity android:name=".GoodsActivity">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
 </application>

引用方式

在Module的gradle目錄下進行引用

修改插件

if (isModuleRun.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

新增applicationId

if (isModuleRun.toBoolean()) {
    applicationId "com.wustor.cartmoudle"
}

切換AndroidManifest文件

sourceSets {
    main {
        if (isModuleRun.toBoolean()) {
            manifest.srcFile 'src/main/debug/AndroidManifest.xml'
        } else {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            java {
                //全部Module一起編譯的時候剔除debug目錄
                exclude '**/debug/**'
            }
        }
    }
}

資源沖突

假如我們在CartModule中定義了一個Application,然后在當前Module中的strings.xml中定義了app_name,同時在OrderModule中的strings.xml中也定義了這個app_name,那么合并你的時候就會出現沖突,我們只可以通過將上述字段分別改成cart_name跟order_name來解決這個問題,在嚴格的開發規范下,可以通過這種差異化命名來解決,因為不同的Module基本上資源文件的名稱基本都不一樣,即時沖突也是少量的沖突,很容易解決。

當然除了這種方式之外可以在build.gradle中給資源文件名添加前綴

resourcePrefix "cart_"

可以強行檢查,命名都需要價格前綴,這樣反而違背了組件化的初衷,使得操作變麻煩了,不過感覺這種方式不是很有必要,當然有時候還可能出現圖片名字相同,這個其實可以還原到組件化之前的項目中分析,是不可能發生的事情,所以歸根到底還是沒有良好的開發規范跟開發習慣造成,沒必要為這種去做一些修改,畢竟約定大于配置

依賴配置

通過最開始的整體架構圖可以看出來,凡是能夠在Library跟Application之間進行切換的Module毫無疑問是需要依賴我們Base的兩個Module的,其實可以合并成一個Module,我這里分了兩個,一個是BaseModule,一個是LibraryModule。下面通過build.gradle中的配置來梳理一下他們的依賴關系:

MainModule
dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile project(':routermodule')
}

編譯期間組件進行隔離,所以MainModule只依賴了RouterModule,剛才說的還有在運行期按需依賴,這里是通過gradle的腳本實現控制的

//編譯期組件隔離,運行期組件按需依賴
//mainModule需要跟cartModule,goodsModule,usersModule進行交互,所以在運行期添加了依賴
def tasks = project.gradle.startParameter.taskNames
for (String task : tasks) {
    def upperName = task.toUpperCase()
    if (upperName.contains("ASSEMBLE") || upperName.contains("INSTALL")) {
        dependencies.add("compile", project.project(':' + 'cartmodule'))
        dependencies.add("compile", project.project(':' + 'goodsmodule'))
        dependencies.add("compile", project.project(':' + 'usermodule'))
        dependencies.add("compile", project.project(':' + 'ordermodule'))
    }
}

BusinessModule

這里指的是Goods/Cart/User/OrderModule,其實是平行的

dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile project(':routermodule')
}

業務Module依賴于RouterModule

RouterModule
dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile project(':modulelib')
    compile 'com.alibaba:arouter-api:1.2.1.1'
}

RouterModule依賴了LibraryModule

BaseModule
dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    testCompile 'junit:junit:4.12'
    compile project(':librarymodule')
}

BaseModule作為一個基礎庫,依賴了LibraryModule

LibraryModule

這個作為最底層的勞苦大眾,實際上就是提供了一個依賴,所以就沒有什么好依賴,只能自己跟自己玩兒。

所以到這里的話,基本的依賴關系已經很清楚了,知道了整個架構圖,接下來進行施工也就很簡單了

組件通信

其實在當初進行模塊劃分的時候,是根據業務來的,所以當我們進入到一個模塊之后,大部分邏輯應該還是在這個模塊內進行處理的,但是偶爾還是會跟別的Module進行打交道,看一個界面

image

就拿GoodsModuleCartModule來說,這兩個Module是可以進行相互跳轉的,在GoodsModule的列表頁面點擊購物車圖標可以進入到CartModule的購物車列表,購物車列表點擊商品也可以進入GoodsModule的商品詳情頁。除了這個跳轉實際上還有變量的獲取,比如在首頁,我需要同時獲取到GoodsModule中的HomeFragment、SortFragment,CartModule中的CartFragment,UserModule中的MineFragment。我是在MainModule中直接依賴了四個業務Module,實際上可以不這樣,我們也可以使用Arouter來進行獲取Fragment的實例。

獲取實例

其實這里的實例大多數情況下指的就是Fragment,下面以Fragment為例,別的實例如法炮制即可

  • 反射獲取

由于模塊間是隔離的,所以我們沒辦法直接創建Fragment的實例,那么這個時候其實很容易想到的就是反射,發射可謂無所不能,下面貼一下代碼。

//獲取Fragment實例
public static Fragment getFragment(String className) {
    Fragment fragment;
    try {
        Class fragmentClass = Class.forName(className);
        fragment = (Fragment) fragmentClass.newInstance();
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
    return fragment;
}

  • Arouter

Arouter是阿里巴巴退出的一款路由框架,在組件中進行路由操作表方便,下面舉例說明

目標Fragment中加入注解

@Route(path = "cart/fragment")
public class CartFragement extends BaseFragment{
}

在任何地方獲取實例

Fragmetn fragment = (Fragment) ARouter.getInstance().build("/cart/fragment").navigation();

方法調用

在不同的Module之間都存在方法的調用,我們可以在每個Module里面定義一個接口,并且實現這個接口,然后在需要調用的地方獲取到這個接口,然后進行方法調用即可。為了統一管理,我們把每個Module的接口都定義在RouterModule里面,然后由于各個業務Module都依賴于這個RouteModule,然后只需要通過反射獲取到這個接口,進行方法調用就可以了。

image

ModuleCall?

Module之間回調的接口

public interface ModuleCall {
   //調用init方法可以傳遞Context參數
    void initContext(Context context);
}

Service接口繼承自ModuleCall可以定義一些回調方法供本身之外的其他Module進行調用

public interface AppService extends ModuleCall {
    //TODO 調用方法自定義
    void showHome();
    void finish();

}

Impl實現類則是對應在每個Module中的具體回調,是實現Service接口的直接子類

public class AppServiceImpl implements AppService {
    @Override
    public void showHome() {
    }
    @Override
    public void finish() {
    }
    @Override
    public void initContext(Context context) {
    }
}

下面還是通過反射跟Arouter兩種方式進行說明

  • 反射調用

    public static Object getModuleCall(String name) {
        T t;
        try {
            Class aClass = Class.forName(name);
            t = (T) aClass.newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        return t;
    }
    
    

獲取接口

AppService appService = (AppService) ReflectUtils.getModuleCall(Path.APP_SERVICE);

其實跟獲取Fragment實例一樣,通過類名來獲取對應的接口,然后調用對應的方法就行,有一點需要注意的就是,如果獲取的接口之后調用的方法需要傳入Context參數,那么在調用接口方法之前必須先調用initContext方法才能使用傳入的Context,不然會報空指針異常。

  • Arouter

Arouter中有一個IProvider接口,如下

public interface IProvider {
    void init(Context var1);
}

其實IProvider跟上面的ModuleCall是一樣的,只不過他在獲取到接口實例之后,就會調用initContext方法,其中的Context來自ARouter.init(this)中傳入的參數,不需要我們再手動調用initContext。

目標類中注入路徑

@Route(path = Path.APP_SERVICE)
public class AppServiceImpl implements AppService {
    private Context mContext;
    @Override
    public void showHome() {
        Log.d("go--->", "home--->");
    }

    @Override
    public void finish() {
    }

    @Override
    public void init(Context context) {
        mContext = context;
    }
}

任意地方獲取目標類

AppService appService = (AppService) RouterUtils.navigation(Path.APP_SERVICE);

然后調用方法即可

UI跳轉

跳轉基本上指的就是Activity之間的跳轉,廢話不多說,依舊是Arouter跟反射

  • 反射

    //將類名轉化為目標類
    public static void startActivityWithName(Context context, String name) {
        try {
            Class clazz = Class.forName(name);
            startActivity(context, clazz);
        } catch (ClassNotFoundException e) {
            throw new RuntimeException(e);
        }
    }
    //獲取Intent
    public static Intent getIntent(Context context, Class clazz) {
        return new Intent(context, clazz);
    }
    //啟動Activity
    public static void startActivity(Context context, Class clazz) {
        context.startActivity(getIntent(context, clazz));
    }
    
    
  • Arouter

    將目標Activity注冊到Arouter

    @Route(path = Path.CART_MOUDLE_CART)
    public class CartActivity extends BaseActivity<UselessPresenter, UselessBean> {
    }
    
    

    啟動目標Activity

     ARouter.getInstance().build(Path.CART_MOUDLE_CART).navigation()
    
    

入口參數

Application

當組件單獨運行的時候,每個Module自成一個APK,那么就意味著會有多個Application,很顯然我們不愿意重復寫這么多代碼,所以我們只需要定義一個ModuleApplication即可,其它的Application直接繼承此ModuleApplication就OK了,看一下結構圖:

image

實際上所有的邏輯都是在ModuleApplication中,業務Module分別有自己的子類,通過子類可以對Application做一些自己的定制化操作。

無參原因

之前在網上看到過攜程以及得到的組件化,他們從MainModule進入到別的Module貌似都是不需要傳參數的,所以不管是組件單獨調試還是所有的Module一起遠行對于從ModuleA跳轉到ModuleB都是不需要傳參的。但是很多時候不同的Module間跳轉是需要傳參的,就拿購物車來說,我單獨調試的時候是需要知道用戶的加密的userId,才能向服務器請求數據,如果是多個Module一起運行,訪問購物車的時候,是可以從別的Module取到userId的,單獨調試的時候就沒法獲取到,也就是入口的時候沒有參數對購物車進行初始化。

解決方式

因為當我們在組件化進行調試的時候,我們每個Module在cartmodule/src/main/debug目錄下有自己的Application,對于入口參數比較簡單的情況,我們可以直接在Application中寫死,而對于一些比較復雜的或者動態的參數,我們可以繼續在此目錄下新疆一個Activity來配置我們單Module調試所需要的參數,然后在整個項目進行編譯的時候剔除debug目錄下的文件。

sourceSets {
    main {
        if (isModuleRun.toBoolean()) {
            manifest.srcFile 'src/main/debug/AndroidManifest.xml'
        } else {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            java {
                //release 時 debug 目錄下文件不需要合并到主工程
                exclude '**/debug/**'
            }
        }
    }
}

總結

項目組件化運行了一段時間,通過劃分Module,單獨調試,確實大大提升了開發效率,隨著使用的時間的推移,也在對組件化的理解也進一步加深,也在不斷地完善,下面幾點是在組件化過程中總結的一些經驗。

  • Module劃分:在劃分Module的時候沒必要劃分地太細,但是要嚴格按照業務來劃分,這樣單獨調試對于習作開發才有意義。
  • Module隔離:業務Module之間應該是相互隔離不可見的,不能相互依賴,如果相互之間需要通信,則必須經過路由轉發,便于統一管理。
  • 面向接口編程:不管是也業務Module還是BaseModule、LibraryModule以及RouterModule,在對外提供服務的時候盡可能的以接口的形式,不同的Module對外提供的服務接口應該都有一個共同的抽象父類,便于管理。
  • 防止循環依賴:循環依賴就是A依賴B,B依賴A,在運行期間動態添加依賴的時候,一定要考慮這個依賴是否被添加到項目中去了,所謂添加到項目中就是但凡被其它的Module進行依賴過就算添加進項目中,不然很容易造成循環依賴。
    github地址:https://github.com/homeven/Androidrouter
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容