Kotlin 编写的android 组件化开发项目demo
一个项目,随着业务的发展,模块会变的越来越多,代码量也会变的异常庞大,进而可能开发的人会越来越多,这种情况下如果还是基于单一工程架构,那就需要每一个开发者都熟悉所有的代码,而且代码之间耦合严重,一个模块穿插着大量其他业务模块的逻辑,严重的话可能使项目处于牵一发而动全身,不想轻易修改的局面;而且庞大的单一工程项目会导致编译速度极慢,开发者长时间等待编译结果,非常不利于开发工作。所以,就需要一个灵活的架构来解决这些问题,组件化架构**应运而生。
- app:壳工程,用于将各个组件组装成一个完成app
- module_base:基础组件部分,不能独立运行,与业务无关,需要所有组件共同依赖的部分,如:网络请求封装、图片加载封装、ui相关基类、工具集合等(这些内容也可以依据分层原则放在不同的基础module中)
- ARouter:阿里开源的路由驱动组件,承载整个项目的路由工作
- module_main:业务组件1,如首页组件,可独立运行
- module_login:业务组件2,如登录组件,可独立运行
- module_me:业务组件3,如个人中心组件,可独立运行
首先,声明全局配置变量,来标识module的属性(app or library)
比如配置以下config.gradle文件
ext {
android = [
//true:组件模式,各组件可以单独运行;false:集成模式,只能运行或打包app module,也就是集成所有的module
isModule : false,
applicationId : "app.android.module",
compileSdkVersion : 28,
minSdkVersion : 19,
targetSdkVersion : 28,
versionCode : 1,
versionName : "1.0.0",
testInstrumentationRunner: "androidx.test.runner.AndroidJUnitRunner",
multiDexEnabled : true,
flavorDimensions : "versionCode",
releaseDebuggable : false,
debugDebuggable : true,
releaseShrinkResources : true,
debugShrinkResources : false,
releaseMinifyEnabled : true,
debugMinifyEnabled : false,
releaseZipAlignEnabled : true,
debugZipAlignEnabled : false
]
java = [
"sourceCompatibility": JavaVersion.VERSION_1_8,
"targetCompatibility": JavaVersion.VERSION_1_8
]
sign = [
"keyPassword" : "123456",
"keyAlias" : "xwh",
"storePassword": "123456",
"storeFile" : "../module.jks"
]
dependencies = [
"appcompatVersion" : "1.0.2",
"constraintlayoutVersion": "1.1.3",
"runnerVersion" : "1.2.0",
"espressocoreVersion" : "3.2.0",
"corektxVersion" : "1.0.2",
"multidexVersion" : "2.0.1",
"junitVersion" : "4.12",
"arouterApiVersion" : "1.4.1",
"arouterCompilerVersion" : "1.2.2"
]
}
配置全部放在根目录的config.gradle文件中,然后在根目录下的build.gradle文件中进行引用
apply from: "config.gradle"
app module只负责集成,里面没有太多代码,只需要在app module的build.gradle添加下面代码即可
dependencies {
if(!rootProject.ext.android.isModule) {
implementation project(':module_main')
implementation project(':module_login')
implementation project(':module_me')
}
}
module_base要特别注意如果组件中有引用其他第三方组件或者自己写的组件,并且还能被其他3个组件访问的话,引用必须要以api的方式,不能是implementation,比如
dependencies {
api fileTree(dir: 'libs', include: ['*.jar'])
api "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
api "androidx.appcompat:appcompat:$rootProject.ext.dependencies.appcompatVersion"
api "androidx.core:core-ktx:$rootProject.ext.dependencies.corektxVersion"
api "androidx.constraintlayout:constraintlayout:$rootProject.ext.dependencies.constraintlayoutVersion"
api "junit:junit:$rootProject.ext.dependencies.junitVersion"
api "androidx.test:runner:$rootProject.ext.dependencies.runnerVersion"
api "androidx.test.espresso:espresso-core:$rootProject.ext.dependencies.espressocoreVersion"
api "androidx.multidex:multidex:$rootProject.ext.dependencies.multidexVersion"
//arouter api,只需在common组件中引入一次
api "com.alibaba:arouter-api:$rootProject.ext.dependencies.arouterApiVersion"
//arouter编译器插件,每个组件都需引入
kapt "com.alibaba:arouter-compiler:$rootProject.ext.dependencies.arouterCompilerVersion"
}
举个例子,A组件引用B组件,B组件引用C组件,如果A组件想使用C组件中的方法,那么B组件引用C组件的时候必须用api,如果用implementation ,A组件是不能访问到C组件的方法的。 module_base组件是公共的,供其他3个组件使用,所以要在每个需要使用它的组件中进行引用
implementation project(':module_base')
业务组件module的配置,比如module_login的build.gradle
if (rootProject.ext.android.isModule) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'
android {
compileSdkVersion rootProject.ext.android.compileSdkVersion
//如果资源文件有相同的名字,前面module的资源文件将替换后面的,Manifest会合并,
// 因此在资源文件前面加前缀(注意:AS不会自动帮我们的资源名自动加上前缀,
// 原来写了这段代码之后,AS会约束我们定义资源时,要我们手动加上前缀,否则报错!!所以只是起约束作用!!)
resourcePrefix "login_"
defaultConfig {
minSdkVersion rootProject.ext.android.minSdkVersion
targetSdkVersion rootProject.ext.android.targetSdkVersion
versionCode rootProject.ext.android.versionCode
versionName rootProject.ext.android.versionName
testInstrumentationRunner rootProject.ext.android.testInstrumentationRunner
}
signingConfigs {
release {
keyAlias rootProject.ext.sign.keyAlias
keyPassword rootProject.ext.sign.keyPassword
storeFile file(rootProject.ext.sign.storeFile)
storePassword rootProject.ext.sign.storePassword
}
}
buildTypes {
release {
debuggable rootProject.ext.android.releaseDebuggable
jniDebuggable rootProject.ext.android.releaseDebuggable
zipAlignEnabled rootProject.ext.android.releaseZipAlignEnabled
if (rootProject.ext.android.isModule) {
//Resource shrinker cannot be used for libraries
shrinkResources rootProject.ext.android.releaseShrinkResources
}
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
debug {
debuggable rootProject.ext.android.debugDebuggable
jniDebuggable rootProject.ext.android.debugDebuggable
zipAlignEnabled rootProject.ext.android.debugZipAlignEnabled
if (rootProject.ext.android.isModule) {
//Resource shrinker cannot be used for libraries
shrinkResources rootProject.ext.android.debugShrinkResources
}
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
sourceSets {
main {
if (rootProject.ext.android.isModule) {
manifest.srcFile 'src/main/module/AndroidManifest.xml'
} else {
manifest.srcFile 'src/main/AndroidManifest.xml'
//集成开发模式下排除module文件夹中的所有文件
java {
exclude 'module/**'
}
}
}
}
compileOptions {
sourceCompatibility rootProject.ext.java.sourceCompatibility
targetCompatibility rootProject.ext.java.targetCompatibility
}
}
//配置arouter编译器参数,每个组件都需配置
kapt {
arguments {
arg("AROUTER_MODULE_NAME", project.getName())
}
}
dependencies {
implementation project(':module_base')
//arouter编译器插件,每个组件都需引入
kapt "com.alibaba:arouter-compiler:$rootProject.ext.dependencies.arouterCompilerVersion"
}
- 3个业务组件,究竟是一个单独的可以运行的组件还是一个library,我们可以通过前面定义的isModule来判断
- 如果资源文件有相同的名字,前面module的资源文件将替换后面的,Manifest会合并, 为了避免集成模式下的命名冲突,因此在资源文件前面加前缀(注意:AS不会自动帮我们的资源名自动加上前缀, 原来写了"resourcePrefix "login_""这段代码之后,AS会约束我们定义资源时,要我们手动加上前缀,否则报错!!所以只是起约束作用!!)
- 当module属性为library时,不能设置applicationId;当为app时,如果未设置applicationId,默认包名为applicationId,所以为了方便,此处不设置applicationId
- 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的路径。
下图是该module的目录
在需要切换module属性的时候改变config.gradle文件中isModule处声明的变量值,然后重新编译即可
在组件化架构中,不同的组件之间是平衡的,不存在相互依赖的关系(可参考文章开头的架构图)。因此,假设在组件A中,想要跳转到组件B中的页面,如果使用Intent显式跳转就行不通了,而且大家都知道,Intent隐式跳转管理起来非常不方便,所以ARouter出现了,并且有强大的技术团队支持,可以放心使用了。那么如何在组件化架构中应用ARouter呢?
- 依赖处理
在module_base组件中将ARouter依赖进来,并配置编译参数;在业务组件中引入ARouter编译器插件,同时配置编译器参数,下面是module_base组件gradle文件的部分片段
//配置arouter编译器参数,每个组件都需配置
kapt {
arguments {
arg("AROUTER_MODULE_NAME", project.getName())
}
}
dependencies {
api fileTree(dir: 'libs', include: ['*.jar'])
api "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
api "androidx.appcompat:appcompat:$rootProject.ext.dependencies.appcompatVersion"
api "androidx.core:core-ktx:$rootProject.ext.dependencies.corektxVersion"
api "androidx.constraintlayout:constraintlayout:$rootProject.ext.dependencies.constraintlayoutVersion"
api "junit:junit:$rootProject.ext.dependencies.junitVersion"
api "androidx.test:runner:$rootProject.ext.dependencies.runnerVersion"
api "androidx.test.espresso:espresso-core:$rootProject.ext.dependencies.espressocoreVersion"
api "androidx.multidex:multidex:$rootProject.ext.dependencies.multidexVersion"
//arouter api,只需在common组件中引入一次
api "com.alibaba:arouter-api:1.4.1"
//arouter编译器插件,每个组件都需引入
kapt "com.alibaba:arouter-compiler:1.2.2"
}
"kapt "com.alibaba:arouter-compiler:1.2.2""必须在每个可跳转的module中引用,因为他会根据注解的类在build中生成对应的文件,比如在module_me中有这样一段代码
@Route(path = ARouterPath.MODULEME_MEACTIVITY)
class MeActivity : BaseActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_me)
ARouter.getInstance().inject(this)
Toast.makeText(applicationContext, intent.extras.getString("param"), Toast.LENGTH_LONG).show()
}
}
那么就会在相应module生成相应的文件
如果我们没有在每个注解的module中添加ARouter依赖,那么在相应的module中就不会生成相应的文件,跳转永远也都不会成功。
- 初始化及编码实现
在组件架构中,经常会遇到组件需要使用全局Context的情况,当组件属性为app时,可以通过自定义Application实现;当组件属性为library时,由于组件被app依赖,导致无法调用app的Application实例,而且自身不存在Application;所以,这里给出的方案是在module_base组件中创建一个BaseApplication,然后让组件模式下的Application继承BaseApplication,在BaseApplication中获取全局Context,并做一些初始化的工作,这里需要初始化ARouter,如下是在module_base组件中声明的BaseApplication。
/**
*描述:Application基类
*
*/
class BaseApplication : Application() {
companion object {
var mContext: Application? = null
//获取全局Context
fun getContext(): Application {
return mContext!!
}
}
override fun onCreate() {
super.onCreate()
mContext = this
//初始化Arouter
initARouter()
//初始化其他第三方库
}
override fun attachBaseContext(base: Context?) {
super.attachBaseContext(base)
MultiDex.install(this)
}
override fun onTerminate() {
super.onTerminate()
//清理Arouter注册表
ARouter.getInstance().destroy()
}
private fun initARouter() {
if (BuildConfig.DEBUG) { // 这两行必须写在init之前,否则这些配置在init过程中将无效
ARouter.openLog() // 打印日志
ARouter.openDebug() // 开启调试模式(如果在InstantRun模式下运行,必须开启调试模式!线上版本需要关闭,否则有安全风险)
}
ARouter.init(this)// 尽可能早,推荐在Application中初始化
}
}
初始化之后,就可以通过@Route注解注册页面,然后调用ARouter api实现页面的跳转了(这里所谓的跨组件页面跳转是指在集成模式下,而非组件模式下)
@Route(path = ARouterPath.MODULEME_MEACTIVITY)
class MeActivity : BaseActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_me)
//注入传递的参数
ARouter.getInstance().inject(this)
Toast.makeText(applicationContext, intent.extras.getString("param"), Toast.LENGTH_LONG).show()
}
}
然后在其他页面调用如下方法就可以跳转到上面路由path指定的目标页面了
ARouter.getInstance().build(ARouterPath.MODULEME_MEACTIVITY).withString("param", "我要到个人中心页面").navigation()
以上便完成了一次简单的跨越组件的页面跳转,仅仅是ARouter的基本使用而已。
说到混淆,有人可能会疑惑,如果在各个组件中混淆可不可以?不建议这样混淆!!因为组件在集成模式下被gradle构建成了release类型的aar包,如果在组件中进行混淆,一旦代码出现了bug,这个时候就很难根据日志去追踪bug产生的原因,而且不同组件分别进行混淆非常不方便维护和修改,这也是不推荐在业务组件中配置buildType(构建类型)的原因。
所以,组件化项目的代码混淆放在集成模式下的app壳工程,各个业务组件不配置混淆。集成模式下在app壳工程.gradle文件的release构建模式下开启混淆,其他buildType配置和普通项目相同,混淆文件放在app壳工程下,各个组件的代码混淆均放在该混淆文件中。
- 解耦:将业务组件代码与工程解耦。
- 提高开发效率:依赖解耦这一优势,团队成员可以只专注于自己负责的组件,开发效率更高;而且,组件开发过程中只需编译自身的module,这样大大缩短了编译时长,避免了漫长的等待编译局面。
- 结构清晰:在业务组件明确拆分的前提下,项目结构变的异常清晰,非常方便全局掌控。
倘若本项目对你有一丝丝的帮助和价值,烦请给个star,或者有什么好的建议或意见,也可以发个issues,谢谢!