一、创建不同的「产品风味」,并为不同产品分配「专有属性」
在app:级别下的gradle文件中,加入productFlavors,并在productFlavors下创建产品A与B
productFlavors {
//新建产品A
A {
//程序包名
applicationId "com.wmj.a"
//不同渠道号
manifestPlaceholders = [UMC:"product-Complete"]
//versionName
versionName "1.0.0"
//versionCode
versionCode 1
// 自定义buildConfig.java中的变量供代码中使用
buildConfigField("String", "APPID", "\"111111\"")
buildConfigField("int", "TYPE", "1")
}
//新建产品B
B {
//程序包名
applicationId "com.wmj.b"
//不同渠道号
manifestPlaceholders = [UMC:"product-Temp"]
//versionName
versionName "2.1.1"
//versionCode
versionCode 2
// 自定义buildConfig.java中的变量供代码中使用
buildConfigField ("String", "APPID", "\"222222\"")
buildConfigField("int", "TYPE", "2")
}
这样,就可以区分A和B两个不同的产品了。A和B分别有自己不同的包名、渠道号、版本号等属性;当然,如果你想区分他们的其他属性比如不同的应用名、应用图标icon、引用不同代码资源、图片资源等等也是可以的;
先在src目录下简历对应的文件夹,比如java代码则建立,product/java,res文件夹则建立product/res
二、配置不同的「开发环境」,并为不同环境配置「专有信息」
有时候我们开发一个产品,需要经过开发环境、测试环境、生产环境等不同环境的测试才能正式发布;而不同的环境可能有不同的服务请求地址、不同的资源地址等等,这时候productFlavors就可以大显身手了。
flavorDimensions 'default'
productFlavors {
sit {
dimension = 'default'
//自定义变量,如:配置sit环境的请求地址,不同环境的请求地址各不相同
buildConfigField "String", "BASE_URL", '"http://123.123.123:8080"'
}
uat {
dimension = 'default'
buildConfigField "String", "BASE_URL", '"http://124.124.124:8081"'
}
pro {
dimension = 'default'
buildConfigField "String", "BASE_URL", '"http://125.125.125:8083"'
}
}
如上,配置了sit、uat、pro三个不同的环境,分别配有不同的服务请求地址,这样就不用每次打不同环境的apk时手动去修改配置文件了。
当然,上面两种使用方式也可以配合一起使用啊!
就可以组合出不同产品在不同环境的apk了。
flavorDimensions("name", "build")
productFlavors {
//产品A
A {
dimension "name"
}
//产品B
B {
dimension "name"
}
//sit环境配置
sit {
dimension = 'build'
//自定义变量,如:配置sit环境的请求地址,不同环境的请求地址各不相同
buildConfigField "String", "BASE_URL", '"http://123.123.123:8080"'
}
//uat环境配置
uat {
dimension = 'build'
buildConfigField "String", "BASE_URL", '"http://124.124.124:8081"'
}
//pro环境配置
pro {
dimension = 'build'
buildConfigField "String", "BASE_URL", '"http://125.125.125:8083"'
}
}
构建变体:[A, B] [sit, uat, pro] [Debug, Release] 到时这样组合就可以构建12个变体了。