最近接触到自定义构建类型 BuildType,发现这一块有些地方稍不注意的话会被绕进去浪费点时间,既然我这边已经花费时间了,如果正好你也需要接触到 BuildType,也许接下来分享的 tips 可能会帮你节省些时间。
缘起
BuildType 相信许多开发者都不陌生,很常见的一种使用场景是线上、线下的后台接口 BaseUrl 不同,许多人会选择在 build.gradle 文件的 buildTypes 中定义全局变量来实现线上线下环境的定义(Gradle 2.x 版本),例如:
buildTypes {
debug {
buildConfigField "String", "BASE_URL", "\"http://debug.api/\""
}
release {
buildConfigField "String", "BASE_URL", "\"https://release.api/\""
}
}
复制代码
在开发过程中,除了默认的 Debug 和 Release 版本,我们可能还需要为程序自定义一些东西。比如在上线 release 版本前,还需要一个预发布版本,该版本除了后台接口的 BaseUrl 与线上版本不同外,其他资源(包括数据库环境)都与线上相同,该版本用来做发布前的最后测试,最大程度避免线上环境出问题。如果每次打预发版本都去直接修改代码中的 BaseUrl 很明显不是最优解。有一种解决方案是自定义 BuildType,在 app 模块下的 build.gradle 的 buildTypes 中自定义新的构建版本:
buildTypes {
debug {
buildConfigField "String", "BASE_URL", "\"http://debug.api/\""
}
release {
buildConfigField "String", "BASE_URL", "\"https://release.api/\""
}
pre.initWith(release)
pre {
buildConfigField "String", "BASE_URL", "\"https://pre.api/\""
}
}
//java 类中调用 BuildConfig.BASE_URL 获取定义的变量
复制代码
initWith()
是 BuildType 的一项配置项,我们还可以看到上文中提到的buildConfigField
其实也是一项配置项。该配置可以理解成initWith(release)
可以理解成拷贝了 release 这一构建类型的所有变量,因为我们知道,每一个构建类型都有一些默认的变量,例如debuggable
、zipAlignEnabled
等,使用该配置就免去为新增的构建类型定义所有的变量。 定义了新的构建类型后,gradle会自动生成新的task,使用gradle assemblePre
即可打包新定义的预发包。这里需要稍微注意的地方就是,必须在 app 模块下的 build.gradle 中定义新的构建类型,gradle 才会生成新的task。
Moduel 中自定义 BuildType 的问题
随着现在模块化开发越来越流行,许多项目都会将一些业务无关的模块独立出去,作为 Moduel 在项目中依赖使用,以此达到复用的效果。很常见的例如网络库可能就会被独立出来,那么上文中的关于就会被定义在子 Module 中。这里不注意的话就会浪费一些时间。假设你在 app 模块与子模块的 build.gradle 的 buildTypes 中都如上文定义了三种类型 debug 、release、pre 版本的BASE_URL
,请注意:
如果你执行了gradle assemblePre
,没错是构建了 pre 版本,但是打印出日志你会发现:
app.BuildConfig.BASE_URL = "https://pre.api/"
module.BuildConfig.BASE_URL = "https://release.api/"
复制代码
子模块中如果没有特别指定构建版本,无论你执行的是gradle assemblePre
还是gradle assembleDebug
,构建的都是 release 版本。可以使用defaultPublishConfig
配置指定需要构建的版本,例如在子模块的 build.gradle 中指定:
android {
...
//指定构建版本
defaultPublishConfig "pre"
...
}
复制代码
当然最好设置个变量,否则如果有许多子模块,不可能修改构建版本时一个一个改过去,常用的是在项目最外层的 build.gradle 中设置变量供子模块调用:
buildscript {
...
dependencies {
classpath 'com.android.tools.build:gradle:2.3.3'
}
...
}
ext {
projectBuildType = "debug"
}
//子模块中引用变量
defaultPublishConfig rootProject.ext.projectBuildType
复制代码
这里需要注意,一旦子模块中指定了构建类型,例如 pre 版本,则该模块的 buildTypes 中必须也要有对应的构建类型 pre,否则编译不通过。并且,一旦指定了构建类型,则该模块的构建类型就只会是指定的类型。举个栗子:子模块中指定了defaultPublishConfig "pre"
,执行gradle assembleRelease
,打印日志:
app.BuildConfig.BASE_URL = "https://release.api/"
module.BuildConfig.BASE_URL = "https://pre.api/"
复制代码
所以这里就会比较烦人,每次打不同的包都需要去修改projectBuildType
的值,还是需要手动修改。
分支名决定构建的版本类型
想要隔离手动修改,网上看到过一种解决方案: 子模块的 build.gradle 中设置:
android {
publishNonDefault true
}
复制代码
然后在模块的依赖处,例如 app 模块的 build.gradle 中改进依赖的写法:
releaseCompile project(path: ':module', configuration: 'release')
debugCompile project(path: ':module', configuration: 'debug')
复制代码
这样就可以实现构建时子模块与 app 模块的类型一致。但这种写法太烦了,如果你有十来个依赖,还得一个一个写过去,又如果你还自定义了不止一种构建类型,且没新增一个新的 buildType 都得修改所有的依赖,我认为也不是最优解。
这里提供一个方案仅供参考。先介绍一下我们的开发流程,例如新开发1.0版本。首先从 master 切出一条 devel1.0 分支用于前期开发阶段,开发完毕达到上线标准后,切出一条 pre1.0 预发分支,打预发包做最后测试并做最后的 bug 修复,最后测试通过,合并代码到 master 分支,打线上包发布至应用商店。不同阶段对应不同的分支,所以不同的构建版本可以通过分支名来决定,git 肯定可以获取当前分支名,而 grale 中则可以执行 cmd 命令,二者结合即可达到想要的效果。有这个思路后实现起来就很简单:
ext {
projectBuildType = "debug"
def gitBranchName = "git rev-parse --abbrev-ref HEAD".execute().text.trim()
if(gitBranchName.contains("master")) {
projectBuildType = "release"
} else if(gitBranchName.contains("pre")) {
projectBuildType = "pre"
}
}
复制代码
Gradle 3.0.0 带来的问题
Android Studio 3.0 + Gradle 3.0 相信许多人都跃跃欲试。升级到 Gradle 3.0 可能需要做一些改动,详情可见Migrate to Android Plugin for Gradle 3.0.0。 Gradle3.0 中自定义 BuildType 有需要注意的地方
Cause of build error
Your app includes a build type that a library dependency does not.
在 Gradle 2.x 时代,如果 app 中定义了 pre 类型,而子模块中没有定义,是不会报错的。但在 Gradle 3.0 下,如果你的 app 包含了新的自定义的 buildType,而依赖库中却没有相应的自定义 buildType,则编译阶段就会报错。
一种解决方案是在子模块里也定义 app 中的所有 buildType,当然,项目里依赖多的同学肯定要吐槽了:我懒!不想修改辣么多东西! Gradle 提供了比 2.x 时代更智能的兼容方案:matchingFallbacks
。
在 buildTypes 中定义 matchingFallbacks
,可以在子模块没找到当前构建类型时指定要加载哪个类型
//app 模块下的 build.gradle 中
buildTypes {
debug {
buildConfigField "String", "BASE_URL", "\"http://debug.api/\""
}
release {
buildConfigField "String", "BASE_URL", "\"https://release.api/\""
}
pre.initWith(release)
pre {
buildConfigField "String", "BASE_URL", "\"https://pre.api/\""
matchingFallbacks = ['pre', 'debug', 'release']
}
}
复制代码
matchingFallbacks 可以定义多个构建类型,当执行gradle assemblePre
构建 Pre 版本时,而恰巧某个子模块又没有定义 pre 版本,则会按照你指定的 matchingFallbacks 从前往后依次寻找,直到类型匹配。这种匹配方案比 Gradle 2.x 时代默认为你构建 release 版本要智能的多,至少我们还可以根据变量来在构建不同类型时定义不同的匹配顺序。并且 Gradle 3.x 中前文提到的defaultPublishConfig
配置已经不再生效了,构建时子模块的构建类型与 app 构建类型保持一致(前提是子模块中也定义了该类型),变得更加灵活。
技术终归是在向前发展的。关于自定义 BuildType 的一些使用小贴士就是这些了,至于更多的关于构建类型相关的知识,例如 buildTypes 结合 productFlavors,或是定义 sourceSets 属性指定不同的代码目录、资源文件目录等知识以后有机会再开一篇聊吧(又挖坑2333)。
啰嗦了一堆,权且算是抛砖引玉。吼啦,下篇博客见~