组件化的项目配置统一管理

缘起

Android开发的都经历过New project的初始阶段,一个工程混所有,只有自己知道,包管理是为了资源管理,包括代码、图片等为程序服务的各种资源.

到了成熟管理一个工程的时候,会继续膨胀各种业务需求,逐渐项目大道可以拆分的时候,就进行组件化,于是就有了A,B,C...组件.一个工程在配置的时候几遍配置项多一些,改一次就可以了,但也会有改错漏改等等的问题.

因此组件化就使这个问题加倍膨胀(目前我手上的除主工程,组件项目就有近60个,可能是我荒谬了,不该拆的也拆),所以统一化的管理也是迫在眉睫.

一番

最原始的使用方式(groovy)

以下列举了单项目引入库方式的衍化过程

apply from: '.\config.gradle' 
dependencies { 
def version '1.10.1' 
api fileTree(include: ['*.jar'], dir: 'libs') 
implementation 'com.androidx.core:core:1.10.1' 
implementation 'com.androidx.core:core:{VERSION}'//VERSION定义在gradle.properties中 
implementation rootProject.ext.dependencies.androidSupportLib//管理在config.gradle中 
implementation rootProject.ext.dependencies.appcompatSupportLib 
implementation rootProject.ext.dependencies.designSupportLib 
implementation(name: 'aar名', ext: 'aar') 
... 
}

二番

组件化,多Moudle共存一个项目,这简单,跟一番里差不多,其实任何东西都是从量变引起质变,中间有那么个过渡,且行且看

//相对路径如下 
apply from: '.\config.gradle'
//绝对路径如下 
//apply from: 'D:\project_android\common\config.gradle' 
//通过系统环境变量如下 
//apply from: getConfigGradle() 
dependencies {
def version '1.10.1' api fileTree(include: ['*.jar'], dir: 'libs') 
implementation 'com.androidx.core:core:1.10.1' 
implementation 'com.androidx.core:core:{VERSION}'//VERSION定义在gradle.properties中 
implementation rootProject.ext.dependencies.androidSupportLib//管理在config.gradle中
implementation rootProject.ext.dependencies.appcompatSupportLib 
implementation rootProject.ext.dependencies.designSupportLib //组件化 implementation project(':组件名') 
implementation(name: 'aar名', ext: 'aar')
... 
}

这里讲讲为什么有个系统环境变量,一切为了自由.

由于多人协作,工作目录有各自的习惯,配个系统环境变量,让同工作的可以自由些(当然更高级的是让配置成为插件,直接apply plugin:'com.xxx.config'即可,这个插件后面再详细讲).

下面先讲一下配置环境变量,跟配java/python环境变量等一个样.我用的WIN11系统,打开环境变量自定义个GRADLE_CONFIG(这个可以自定名称)

image.png

以下是获取config.gradle的(groovy)函数

//获取gradle配置文件目录 
def gradleConfig() { 
    String gradleConfigPath = System.getenv("GRADLE_CONFIG") 
    println 'gradleConfigPath:' + gradleConfigPath 
    return gradleConfigPath; 
} 
//获取gradle Version版本管理文件 
def gradleVersionScript() { 
    String configScript = gradleConfig() + System.getProperty('file.separator') + 'config.gradle'; 
    println 'configScript:' + configScript return configScript; 
}

此处应有掌声,因为这就可以管理很多自定义的xxx.gradle了,这样只有一份配置文件,改也就改一个,或许你还没想这么用,如果要准备工程化组件,不防试试这个方式.

以下是config.gradle的内容,举个栗子

ext { 
buildGradle="com.android.tools.build:gradle:8.1.2" 
alipushVer="3.8.6"
android = [ 
    androidBuildToolsVersion: "33.0.0",
    androidCompileSdkVersion: 33, 
    androidTargetSdkVersion : 33,
    androidMinSdkVersion : 21, 
    compatibility : JavaVersion.VERSION_11 
] 
dependencies = [ 
    androidxCore : "androidx.core:core:1.8.0", 
    androidSupportAnnotations : "androidx.annotation:annotation:1.5.0",
    androiSupportPalette : "androidx.palette:palette:1.0.0", 
    cardview : "androidx.cardview:cardview:1.0.0", 
    constraintLayout : "androidx.constraintlayout:constraintlayout:2.1.4",
    ... 
] 
...
}

诶嘿,使用起来多个组件分开成工程,就不用每个工程都有一份库配置文件了,这样也做到了工程化,统一化.

三番

这一番作为本文的结尾,但不是这个"组件化的项目配置统一管理"的结束.

不知道有多少能看到这篇我分享的"总结",哈哈,第一次写,都是现成的东西,不过都是自己一步步扣过来的.先预告一下

1.通过groovy脚本定义函数配置引入库

2.libs.versions.toml的结合

3.配置管理打包成为plugin

对于预告的第三点这部分说实话还没实践过,网上的教程一抓一大把,这里加入主要是想把自己以上实践过的结合起来,应该可以吧

说实话,其实还有一块想详细讲讲,versionBuilds/composingBuilds/gradle plugin

其实就是Transform的内容,奈何官方在Gradle8.0+以后要废弃了这个,换了一套,这个网上也是一大堆,索性就以后再说吧.

题外话,目前Android被各种狙击,北上广很多30刚出头就遇到了35的危机,各种咔咔咔背刺(辞退),现在经济不好,大到企业小到个人,都难~所以这里分享的不仅仅是某一领域的技术,还有思想,如果换了个赛道或行业都可以作为借鉴(思想,思想,思想).

感谢您花费宝贵的时间看到这(不知道能看到的有多少小伙伴),祝大家万事皆顺!
(转载请写明出处,本文皆为本人一字字码出来的,写的不易,谢谢)