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

时间 2019-11-06

标签基于 arouter 实现组件方案说明繁體版

原文原文链接

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

组件化背景

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

总体结构

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

组件化所面临的问题：

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

组件化的实现

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

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

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

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呢？下面详细来聊一聊app

依赖处理

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

    
//配置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注册表
        ARouter.getInstance().destroy()
    }
}
复制代码

根据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的基本使用而已。解决了组件间页面跳转的问题后，咱们来看看组件之间通讯、调用彼此服务的实现。gradle

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

组件间通讯功能和路由功能有着共通的地方，即都是利用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，这样大大缩短了编译时长，避免了漫长的等待编译局面。
结构清晰：在业务组件明确拆分的前提下，项目结构变的异常清晰，很是方便全局掌控。