基于Arouter实现的组件化方案说明

基于Arouter实现的组件化方案说明:

组件化背景

一个项目，随着业务的发展，模块会变的越来越多，代码量也会变的异常庞大，进而可能开发的人会越来越多，这种情况下如果还是基于单一工程架构，那就需要每一个开发者都熟悉所有的代码，而且代码之间耦合严重，一个模块穿插着大量其他业务模块的逻辑，严重的话可能使项目处于牵一发而动全身，不想轻易修改的局面；而且庞大的单一工程项目会导致编译速度极慢，开发者长时间等待编译结果，非常不利于开发工作。所以，就需要一个灵活的架构来解决这些问题，组件化架构思想应运而生。

整体结构

common：基础组件部分，与业务无关，需要所有组件共同依赖的部分，如：网络请求封装、图片加载封装、ui相关基类、工具集合等（当然这些内容可以依据分层原则放在不同的基础module中）
router-comp：路由驱动组件，承载整个项目的路由工作
comp1：业务组件1，如视频组件，可独立运行
comp2：业务组件2，如新闻组件，可独立运行
comp3：业务组件3，如视频组件，可独立运行
app：壳工程，用于将各个组件组装成一个完成app

组件化所面临的问题：

集成模式与组件模式转换(热插拔)
组件之间页面跳转(路由)
组件之间通信、调用彼此服务
打包混淆

组件化的实现

针对上面所说的几个问题，下面我们逐个说明它们的解决方案，当解决完这些问题，你会发现，你已经搭建了一个基于组件化的项目。下图是一个完整的组件化项目结构：common是基础组件module，作为library存在，需要所有组件依赖；comp1、comp2作为组件存在，可配置成library或可独立运行的module；app是个壳，通过组装组件实现其价值。

集成模式与组件模式转换(热插拔)

Android工程通过gradle构建，通过配置每个module的gradle，来实现module的不同表现。Android Studio的module有两种属性，分别是：

application属性：可独立运行，也就是我们的app
library属性：不可独立运行，被app依赖的库

module属性通过其目录下的gradle文件配置，当module属性为application时，该module作为完整的app存在，可以独自运行，方便编译和调试；当module属性为library时，该module作为一个依赖库，被壳工程依赖并组装成一个app。那么如何让这两种模式可以自动转换呢？如果每次切换模式的时候，都手动去修改每个组件的配置，组件少的情况下还可以接受，组件多了会非常不方便，下面就让我们来聊聊如何实现两种模式的自动转换。

首先，声明全局配置变量，来标识module的属性(app or library),如在工程目录下的build.gradle文件中声明布尔变量ext.isModule，true代表组件作为可独立运行的app，false代表组件作为被依赖的library，如下所示


buildscript {
    ext.kotlin_version = '1.3.21'
    ext.isModule = true  //true-每个组件都是单独的module，可独立运行  false-组件作为library存在
    repositories {
        google()
        jcenter()
    }
   
}

配置组件的build.gradle文件

    
//1
if (rootProject.ext.isModule) {
    //可独立运行的app
    apply plugin: 'com.android.application'
} else{
    //被依赖的library
    apply plugin: 'com.android.library'
}
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'

android {
    compileSdkVersion 28
    defaultConfig {
      
      //applicationId "com.study.comp1" //2 如果没有，默认包名为applicationId
        minSdkVersion 19
        targetSdkVersion 28
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }
    //3
    sourceSets {
        main {
            if(rootProject.ext.isModule){
                manifest.srcFile 'src/main/java/module/AndroidManifest.xml'
            } else{
                manifest.srcFile 'src/main/java/library/AndroidManifest.xml'
                java {//移除module包下的代码
                    exclude 'module'
                }
            }
        }
    }
}

上面是截取的组件gradle的部分代码，包含了组件化需要配置的所有内容，每一点都进行了注释

注释1：如上所述，根据isModule的值，来设置module的属性，作为app or library
注释2：当module属性为library时，不能设置applicationId；当为app时，如果未设置applicationId，默认包名为applicationId，所以为了方便，此处不设置applicationId
注释3：Android Studio会为每个module生成对应的AndroidManifest.xml文件，声明自身需要的权限、四大组件、数据等内容；当module属性为app时，其对应的AndroidManifest.xml需要具备完整app所需要的所有配置，尤其是声明Application和launch的Activity；当module属性为library时，如果每个组件都声明自己的Application和launch的Activity，那在合并的时候就会发生冲突，编译也不会通过，所以，就需要为当前module重新定义一个AndroidManifest.xml文件，不声明Application和launch的Activity，然后根据isModule的值指定AndroidManifest.xml的路径，因此就有了注释3处的写法。为了避免集成模式下的命名冲突，每个文件都以自身module名为前缀来命名会是一个很好的方法。下图是该module的目录

在需要切换module属性的时候改变步骤1处声明的变量值，然后重新编译即可

组件之间页面跳转(路由)

在组件化架构中，不同的组件之间是平衡的，不存在相互依赖的关系(可参考文章开头的架构图)。因此，假设在组件A中，想要跳转到组件B中的页面，如果使用Intent显式跳转就行不通了，而且大家都知道，Intent隐式跳转管理起来非常不方便，所以Arouter出现了，并且有强大的技术团队支持，可以放心使用了。那么如何在组件化架构中应用Arouter呢？下面详细来聊一聊

依赖处理

在common组件中将Arouter依赖进来，并配置编译参数；在业务组件中引入arouter编译器插件，同时配置编译器参数，下面是Common组件gradle文件的部分片段

    
//配置arouter编译器参数，每个组件都需配置
kapt {
    arguments {
        arg("AROUTER_MODULE_NAME", project.getName())
    }
}

dependencies {
    //arouter api，只需在common组件中引入一次
    api('com.alibaba:arouter-api:1.4.1') {
        exclude group: 'com.android.support'
    }
    //arouter编译器插件，每个组件都需引入
    kapt 'com.alibaba:arouter-compiler:1.2.2'
}

初始化及编码实现

在组件架构中，经常会遇到组件需要使用全局Context的情况，当组件属性为app时，可以通过自定义Application实现；当组件属性为library时，由于组件被app依赖，导致无法调用app的Application实例，而且自身不存在Application；所以，这里给出的方案是在common组件中创建一个BaseApplication，然后让集成模式(组件模式)下的Application继承BaseApplication,在BaseApplication中获取全局Context，并做一些初始化的工作，这里需要初始化Arouter，如下是在common组件中声明的BaseApplication


abstract class BaseApplication : Application() {

    companion object {
        var _context: Application? = null
        //获取全局Context
        fun getContext(): Application {
            return _context!!
        }
    }
    override fun onCreate() {
        super.onCreate()
        _context = this
        //初始化Arouter
        initARouter()
        //初始化其他第三方库
    }
    private fun initARouter() {
        if (BuildConfig.DEBUG) {
            ARouter.openDebug()
            ARouter.openLog()
        }
        ARouter.init(this)
    }
    override fun onTerminate() {
        super.onTerminate()
    }
}

根据Arouter的路由特性，初始化之后，就可以通过@Route注解注册页面，然后调用Arouter api实现页面的跳转了（这里所谓的跨组件页面跳转是指在集成模式下，而非组件模式下），无关乎是否在同一个组件下面，假设我们要从组件1页面携带参数跳转到组件2页面，请看下面示例


/**
 * 在组件2中通过@Route注解注册该页面
 */
@Route(path = "/comp2/msg",name = "我是组件2的MSGActivity")
class Comp2MsgActivity : BaseActivity() {
    //传递过来的参数
    @Autowired(name = "msg")
    @JvmField
    var msg: String? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //注入传递的参数
        ARouter.getInstance().inject(this)
        setContentView(R.layout.comp2_activity_msg)
        comp2_msg_msg.text = msg!!
    }
}

//在组件1中发起跳转命令
ARouter.getInstance()
                    .build("/comp2/msg")
                    .withString("msg", "hello Im from Comp1")
                    .addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
                    .navigation()

以上便完成了一次简单的跨越组件的页面跳转，仅仅是Arouter的基本使用而已。解决了组件间页面跳转的问题后，我们来看看组件之间通信、调用彼此服务的实现。

组件之间通信、调用彼此服务

组件间通信功能和路由功能有着共通的地方，即都是利用Arouter的基础功能实现，在Arouter驱动层定义各个组件对外提供的接口，然后在组件自身模块实现该接口，通过Arouter调用其他组件服务。假设我们在组件2中需要调用组件1中的服务，可以总结为以下3点

定义接口：在common组件中定义组件1对外提供的接口CompServer1，注意该接口类型为Arouter模板类型IProvider


/**
 * 组件1对外提供的接口
 */
interface CompServer1 : IProvider {
    fun showMsg(msg: String)
}

实现接口：在comm1中实现上面定义的接口，并通过@Route注解注册


@Route(path = "/comp1/server",name = "comp1对外提供的服务")
class CompServer : CompServer1 {
    var mContext: Context? = null
    override fun showMsg(msg: String) {
        Toast.makeText(mContext,msg,Toast.LENGTH_SHORT).show()
    }
    override fun init(context: Context?) {
        this.mContext = context!!
    }
}

调用服务：在完成组件1接口的定义和实现之后，在组件2中需要的地方调用该接口即可


val server1 = ARouter.getInstance().build("/comp1/server").navigation() as CompServer1
server1.showMsg("我从comp2吊起了comp1的接口")

有没有感觉很简单？？没错，就是这么简单，赶紧去用吧!哈哈

打包混淆

说到混淆，有人可能会疑惑，如果在各个组件中混淆可不可以？不建议这样混淆！！因为组件在集成模式下被gradle构建成了release类型的aar包，如果在组件中进行混淆，一旦代码出现了bug，这个时候就很难根据日志去追踪bug产生的原因，而且不同组件分别进行混淆非常不方便维护和修改，这也是不推荐在业务组件中配置buildType(构建类型)的原因。

所以，组件化项目的代码混淆放在集成模式下的app壳工程，各个业务组件不配置混淆。集成模式下在app壳工程.gradle文件的release构建模式下开启混淆，其他buildType配置和普通项目相同，混淆文件放在app壳工程下，各个组件的代码混淆均放在该混淆文件中。

小结

以上，我们已经逐一解决了组件化所面对的各个问题，至此，我们已经搭建了一个简单的组件化架构的项目，这一起感觉是在不知不觉中就实现了，并不是很难哦！现在，我们总结一下组件化的优势了

解耦：将业务组件代码90%与工程解耦，只所以是90%而非100%，是因为业务组件需要在common组件中声明对外开放的接口，那有没有什么方式可以做到完全解耦呢？目前还没有发现更好的办法。。。
提高开发效率：依赖解耦这一优势，团队成员可以只专注于自己负责的组件，开发效率更高；而且，组件开发过程中只需编译自身的module，这样大大缩短了编译时长，避免了漫长的等待编译局面。
结构清晰：在业务组件明确拆分的前提下，项目结构变的异常清晰，非常方便全局掌控。