Android组件化探索之Library productFlavors

组件化 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。