概述
組件化緣由
記得剛開始接觸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以我自己的項目為例,放兩張組件化之前跟之后的圖對比一下。
可以明顯的發現我們的Module變多了,就像MVC切換到MVP之后,需要寫很多的Presenter組件化最大的好處就是可以模塊可以單獨開發調試,這樣效率一下子就上來了,還是拿購物車舉例,購物車實際上就只有一個界面,也就是一個Fragment,加上啟動頁跟Fragment的父Activity,也就兩個界面,可以說想慢都慢不下來,下面就我在組件化過程中遇到的一些問題進行總結一下。
正文
指導思想
組件拆分
組件化的目的在于將一個project劃分成業務組件、基礎組件、路由組件。其中業務組件是相互隔離的,可以單獨調試,基礎組件提供業務組件所公用的功能,路由組件為業務組件之間通信提供支持。
一般來講,一個APP可以由一個app殼,然后集成多個Module,這是理想的情況,但是從運營的需求到產品的設計到UI出圖,可能你就會對組件化很絕望,并不是那么的理想,很多時候我們程序入口所在的Module實際上跟其它很多Module是關聯的,實際上沒法拆分,本文將會以這種比較復雜的情況進行組件化分析。
組件隔離
組件化的一個很大的特性在于可以單獨調試,但是由于業務組件之間的隔離,所以導致了多個組件之間無法進行通信,其實我覺得是很正常的,既然是單獨調試,就必然不應該跟其它的Module間進行依賴,不管是編譯期還是運行期都應如此,不然組件化就沒有任何意義了,但是由于我們的業務組件都是相互關聯的,如果不依賴其他的組件的話,作為一個單獨的APP運行有時候是需要參數的,鑒于此,我們可以在Application初始化的時候,新增一個頁面作為參數配置,或者直接在Application中固定寫死。
核心法則
不管我們如何劃分,如何依賴,組件間的關系都要嚴格遵守一個準則:編譯器隔離,運行期按需依賴。
整體架構
通過組件化將項目按照業務進行化分成GoodsModule,CartModule,UserModule,OrderModule四個模塊,模塊間通過RouterModule進行通信,也就是說業務組件依賴于路由組件,RouterModule依賴于Base,也就是BaseModule,LibraryModule,基礎庫跟第三方庫,然后MainModule實際上相當于程序的入口跟容器,通過MainModule依賴上述四個Module,完成整個APP的打包。
當然在單獨調試的時候,GoodsModule,CartModule,UserModule,OrderModule又各自成為一個APP,可以單獨進行調試,這樣就實現了APP的組件化,下面就組件化過程中遇到的一些問題總結一下。
組件化分析
在組件化的過程中,由于Module之間是隔離的,所以就產生了一系?列問題,現在就組件化前后的遇到的問題總結如下:
- 組件劃分:如何根據業務對項目進行Module劃分
- 模式切換:如何使得APP在單獨調試跟整體調試自由切換
- 資源沖突:當我們創建了多個Module的時候,如何解決相同資源文件名合并的沖突
- 依賴關系:多個Module之間如何引用一些共同的library以及工具類
- 組件通信:組件化之后,Module之間是相互隔離的,如何進行UI跳轉以及方法調用
- 入口參數:我們知道組件之間是有聯系的,所以在單獨調試的時候如何拿到其它的Module傳遞過來的參數
接下來會根據?這幾個問題,提出對應的解決方法
組件劃分
業務劃分
由于我們做的是一個電商項目,網上也查找了很多資料,感覺他們舉的例子都有些過于簡單,因為模塊間基本上沒有什么耦合,所以很好拆分,不過還是很感謝他們提供了一種解決思路。玩過京東,淘寶都知道,大致分為幾個大的模塊:商品模塊,購物車模塊,訂單模塊,用戶模塊。沒錯,我也是這么拆分我們APP的。但是拆著拆著就發現問題了,模塊間耦合性太高,我們過了SplashActivity之后就是MainActivity,看圖說話
所以網上的一些一進來就是一個空的APP殼的方法并不適用,從一開始就遇到了這個棘手的問題,有點尷尬,按照之前的模塊劃分,在用戶登陸的情況下MainModule一進來就必須拿到GoodsModule,CartModule以及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進行打交道,看一個界面
就拿GoodsModule跟CartModule來說,這兩個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,然后只需要通過反射獲取到這個接口,進行方法調用就可以了。
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了,看一下結構圖:
實際上所有的邏輯都是在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