概述

組件化緣由

記得剛開始接觸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

通過組件化將項目按照業務進行化分成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，看圖說話

image

所以網上的一些一進來就是一個空的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進行打交道，看一個界面

image

就拿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，然后只需要通過反射獲取到這個接口，進行方法調用就可以了。

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