概述

在日常开发中，开发项目的时候可能要在测试环境中开发，上线之后又要换一套环境，因为要避免测试环境和线上环境的数据互相混淆，在切换环境的时候你可能要更换域名，更换apk的签名文件，更换第三方申请的key或是关闭日志等等

当然这还是比较简单的情况，随着项目规模的扩大，要保证项目的可靠性，可能又要增加新环境，比如像预生产环境，给投资人展示项目又要用到演示环境，演示环境可能就要简化一些流程，在短时间内给客户展示核心功能，这不只是配置不一样了，连很多代码的实现逻辑流程都不一样了

项目小的时候或许只需要写个清单去挨个替换掉，但项目一大不仅重复工作增加，并且还容易出错，这时候就要用的gradle的多环境自动化配置，保证切换环境的时候快捷安全；

相信大家都用过svn或是git等代码管理工具，其实gradle多环境配置也属于代码管理工具，如果要区分他们有什么不同，那就是svn/git是属于代码纵向管理工具，gradle多环境是属于代码横向管理工具

构建多环境的两种方式

1.buildTypes

buildTypes主要用于环境的区分，不同的环境采用不同的配置
可以在file->project structure去配置，选择主项目，可以看到项目默认有debug和release两个环境，在这里配置可以显示在主项目的builde.gradle的android{}下：

默认的两个环境

buildTypes的常用属性：

minifyEnabled:是否开启混淆
debuggable：是否允许断点调试
applicationIdSuffix：包名增加后缀
javaCompileOptions：配置Java编译选项
jniDebuggable：此构建类型是否配置为生成具有可调试本机代码的APK
manifestPlaceholders manifest明示占位符
multiDexEnabled：是否限制方法数65535
name：生成的apk名字
proguardFiles：返回要使用的ProGuard配置文件。
shrinkResources：是否启用未使用资源的收缩。默认值为false
testCoverageEnabled：是否为此构建类型启用了测试覆盖率。
versionNameSuffix：版本名称后缀。

常用方法：

buildConfigField(type, name, value)：向生成的BuildConfig类添加一个新字段，和buildTypes的常用属性一样，可以在BuildConfig中直接取到
consumerProguardFile(proguardFile)：添加要包含在已发布的AAR中的proguard规则文件。
consumerProguardFiles(proguardFiles)：添加要包含在已发布的AAR中的proguard规则文件。
externalNativeBuild(action)：配置本机构建选项。
initWith(that)：从给定的构建类型复制所有属性。
proguardFile(proguardFile)：添加一个新的ProGuard配置文件。
proguardFiles(files)：添加新的ProGuard配置文件。
resValue(type, name, value)：添加新生成的资源
setProguardFiles(proguardFileIterable)：设置ProGuard配置文件。

initWith,比如你要新建一个预生产环境pre，这个环境大部分属性都和release一样，只有一个minifyEnabled属性不相同,可以写成

buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
            signingConfig signingConfigs.release
        }
        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
            signingConfig signingConfigs.debug
        }
        pre{
            initWith release
            minifyEnabled false
        }
    }

resValue是重新生成资源,比如我们在debug环境中使用resValue，如下

debug {
    minifyEnabled false
    signingConfig signingConfigs.debug
    resValue "string", "AppName", "CustomName"
}

就可以在目录app\build\generated\res\resValues\debug\values\gradleResValues.xml
中发现相应的字段

image.png

2.Flavors

第二种构建方式Flavors其实和buildTypes在用法上差别不大，比如Flavors的一些属性，如buildConfigField，manifestPlaceholders，applicationIdSuffix等等，都buildTypes的用法都一样，都可以在BuildConfig中直接获取到，同样也是配置在build.gradle的android{}下

如果buildTypes和Flavors完全一样，也就没必要设计出来了，最大的不同就是Flavors可以配置不同的代码，可以配置不同的assets资源文件和res资源文件，而这些只用配置的方式不能实现

来实现一个例子，比如在项目中测试的时候需要屏蔽一些登录流程，这时候不同环境下的LoginActivity类实现就不一样，在比如，像第三方SDK mob分享，就要在assets文件中定义分享平台的key,不用环境需要不同的key,那么，建立两个Flavors就可以实现不同环境先登录流程的不同和sharekey的不同
打开file->project structure->Build Variants->Flavors,选中主项目，建立login和share两个Flavors

productFlavors {
    login {
    }
    share {
    }
}

加上之前建立的debug,release和pre环境，我们查看Builde Variant就发现有6个环境了（2*3）

image.png

完成之后，之前的debug,release和pre环境都能分别实现两种不同登录逻辑和sharekey的配置

替换src的代码

接下来就要在不同环境配置登录逻辑
在原有的目录中，有一个LoginActivity

image.png

要在login的Flavors环境中替换LoginActivity,首先要在src目录下建立一个和Flavors环境名字一样的目录login

image.png

因为要替换掉住项目中的LoginActivity,所以就要建立和LoginActivity相同的路径，LoginActivity的路径是java.com.dj.combat.multienvironment.LoginActivity,所以在新建的login目录下也要如此,建好之后就变成了这样

image.png
在LoginActivity中加入你的新逻辑就可以了

替换assets资源文件

替换assets资源文件和src里面的代码没什么区别，在主环境中，assets和java是同一目录

image.png

我们在刚才建立的login环境里面加入assets也是同样的

image.png ，和main里面的assets文件同路径，名字相同就可以实现替换，如要替换main中的assets的custom.xml
image.png

同样的，res里面的文件也可以用此方法实现替换