迁移至Gradle 3.+：带多Flavor依赖库的编译配置问题

我太懂这种在复杂Gradle项目里卡壳的感觉了——一堆相互依赖的库，文档视频翻遍了还是摸不清Flavor配置的门道，更别说把老旧的compile换成implementation了。别慌，我给你捋清楚一步步该怎么做：

compile早在Android Gradle Plugin 3.0之后就被废弃了，替换成implementation是基础操作，而且逻辑更清晰：

• 打开项目里所有模块的build.gradle（如果用KTS就是build.gradle.kts），把所有compile关键字直接替换成implementation。比如原来的：

  compile 'com.example:some-core-lib:1.2.3'
  

  改成：

  implementation 'com.example:some-core-lib:1.2.3'
  

• 别忘了测试相关的依赖：testCompile要换成testImplementation，androidTestCompile换成androidTestImplementation，规则和主依赖完全一致。

如果你的项目有Flavor（比如区分开发/生产环境、不同版本变体），要让依赖和Flavor绑定，分两种常见场景处理：

场景1：不同Flavor用不同的依赖 #

比如你有dev和prod两个Flavor，想给开发环境用调试工具，生产环境用正式版统计库：

android {
    // 先定义Flavor维度，所有Flavor都要归属同一个维度
    flavorDimensions "environment"
    productFlavors {
        dev {
            dimension "environment"
            // 可以加Flavor专属配置，比如applicationIdSuffix ".dev"
        }
        prod {
            dimension "environment"
        }
    }
}

dependencies {
    // 所有Flavor通用的基础依赖
    implementation 'com.example:common-utils:2.0.0'
    
    // 仅dev Flavor生效的依赖
    devImplementation 'com.example:debug-tools:1.5.0'
    
    // 仅prod Flavor生效的依赖
    prodImplementation 'com.example:official-analytics:3.0.0'
}

核心就是用[你的Flavor名称]Implementation的命名格式，Gradle会自动识别对应Flavor的依赖。

场景2：库模块也有对应Flavor，和App模块对齐 #

如果你的项目里有多个自研库模块，这些库也和App一样有相同的Flavor（比如App有dev/prod，库也有对应变体），要让它们的Flavor自动匹配：

1. 先确保所有库模块的build.gradle里，定义了和App完全一致的flavorDimensions和Flavor：

   android {
       flavorDimensions "environment"
       productFlavors {
           dev { dimension "environment" }
           prod { dimension "environment" }
       }
   }
   

2. 然后在App模块的依赖里，直接引用库模块即可：

   implementation project(':your-library-module')
   

   Gradle会自动根据当前构建的Flavor变体，拉取对应库的同变体依赖。比如构建devDebug时，会自动用your-library-module的devDebug版本。

implementation和旧的compile最大的区别是：implementation的依赖不会传递给上层模块。如果你的库模块需要让App模块能访问它的某个依赖（比如库用了Gson，App也要直接用Gson），那就要把库模块里对应的implementation改成api：

// 库模块中，如果希望上层模块能直接用这个依赖，用api
api 'com.google.code.gson:gson:2.10.1'
// 如果只是库自己内部用，不需要上层访问，用implementation就行
implementation 'com.example:internal-helper:1.0.0'

要是忽略这点，很可能会出现编译错误（比如找不到某个类），这时候排查一下是不是依赖没传递下去就行。

改完所有配置后，先执行一次清理构建：

# Mac/Linux
./gradlew clean build

# Windows
gradlew clean build

如果出现编译错误，优先排查这几点：

• 是不是所有模块的flavorDimensions和Flavor名称完全一致？
• 有没有漏替换的compile关键字？
• 是不是依赖传递的问题，需要把部分implementation改成api？

内容的提问来源于stack exchange，提问作者Eugene H