Android 自定义构建类型 BuildType

最近接触到自定义构建类型 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）。

啰嗦了一堆，权且算是抛砖引玉。吼啦，下篇博客见~