标签： 组件化 productFlavors
问题背景
组件化的时候，会有一个App module（主module），多个业务module，一堆lib module。现在假如App module是App.module，有一个业务module叫login.module，还有一个lib module叫lib.module。组件化是一个项目解耦的过程，所以需要把每个业务module公用的功能抽离到lib.module中比如网络请求模块，假如叫networkUtil，networkUtil进行网络请求的host地址是需要根据当前编译打包的productFlavors来区分的，之前我们习惯把productFlavors配置在App.module的build.gradle中
比如这样
productFlavors {
dev {
buildConfigField("String", "env", properties.getProperty("env"))
}
rel {
buildConfigField("String", "env", properties.getProperty("env"))
}
}
但是要把网络请求相关东西都抽离在lib.module，所以也需要在lib.module中配置productFlavors，而且还需要让lib.module中的productFlavors在编译时始终和App.module的productFlavors保持一致，才能保证项目环境的实时有效性，这篇文章就解释一下如何实现这种需求。
配置方式
- lib.module中需要配置和App.module中大致相同的productFlavors
publishNonDefault true //注意，这里的配置是为了去除gradle对library module默认只编译release buildType的限制
productFlavors {
dev {
buildConfigField("String", "env", properties.getProperty("env"))
}
rel {
buildConfigField("String", "env", properties.getProperty("env"))
}
}
- App.module中需要在dependencies中增加compile支持
devCompile project(path: ':lib.module', configuration: 'devRelease')
relCompile project(path: ':lib.module', configuration: 'relRelease')
这样就已经可以实现问题背景中描述的需求，实现lib.module的productFlavors跟随App.module中productFlavors动态保持一致（可以通过在studio中配置不同的Build Variants来测试效果）。其实不管是Application module，还是一个library module，只要需要依赖lib.module，都需要在自身的build.gradle中配置同样的productFlavors。
