缘起
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(这个可以自定名称)
以下是获取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的危机,各种咔咔咔背刺(辞退),现在经济不好,大到企业小到个人,都难~所以这里分享的不仅仅是某一领域的技术,还有思想,如果换了个赛道或行业都可以作为借鉴(思想,思想,思想).
感谢您花费宝贵的时间看到这(不知道能看到的有多少小伙伴),祝大家万事皆顺!
(转载请写明出处,本文皆为本人一字字码出来的,写的不易,谢谢)
