基于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注册表
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的基本使用而已。解决了组件间页面跳转的问题后,我们来看看组件之间通信、调用彼此服务的实现。
组件之间通信、调用彼此服务
组件间通信功能和路由功能有着共通的地方,即都是利用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,这样大大缩短了编译时长,避免了漫长的等待编译局面。
- 结构清晰:在业务组件明确拆分的前提下,项目结构变的异常清晰,非常方便全局掌控。
喜欢点击+关注哦
![](http://img.e-com-net.com/image/info10/ed3d9570c9864ed29e55e6d4fa7b49d4.gif)