解读

国内大厂（如阿里、腾讯、字节）的 Android 项目往往要同时应对“渠道”“国家”“付费模式”“硬件形态”等多条业务线。早期用单一 flavor 枚举，build.gradle 里很快出现 3×4×2=24 个 flavor，维护成本爆炸。FlavorDimensions 是 Google 在 3.0 引入的“维度”概念，把 flavor 按业务语义分组，Gradle 自动做笛卡尔积，既减少样板代码，又保证编译期就能发现冲突，是面试里“构建提速/多包并行”必考点。面试官想确认：

1. 维度语义与声明位置；
2. 冲突类型（资源、Manifest、依赖、代码）；
3. 解决策略与优先级规则；
4. 在 CI、缓存、增量编译中的实战细节。

知识点

1. 维度声明：android.flavorDimensions 列表顺序即优先级，越靠前越高。
2. 组合规则：Gradle 对同一维度内只能选 1 个 flavor，跨维度做笛卡尔积，生成 “维度1维度2…” 拼接的 BuildVariant。
3. 冲突优先级：
   buildType < productFlavor < flavorDimensions 靠前维度 < 靠后维度 < main。
4. 覆盖策略：
   resValue/ manifestPlaceholders 采用“后者覆盖前者”；
   资源文件以“路径最深”胜出；
   Java/Kotlin 源码按“先主后 flavor”顺序组成 sourceSet，重复类编译期报错，需用同包同名类做合并或隔离。
5. 国内常用维度示例：
   channel（华为、小米、应用宝）、region（cn、global）、api（oss、aws）、screen（fold、normal）。
6. 冲突解决 API：
   missingDimensionStrategy、matchingFallbacks、exclude、pickFirst、sourceSets.flavorName.java.srcDir、android.packagingOptions。
7. CI 提速：维度组合数爆炸时，用 gradle.properties 的 #FLAVOR# 占位符 + 矩阵构建，配合 gradle-build-cache 与 freeline/gradle daemon，单 variant 增量 10 s 内。
8. 合规场景：国内渠道包必须关闭 GMS，海外必须打开，通过 dimension=region 在 CI 阶段自动注入签名与隐私权限，避免人工错包。

答案

FlavorDimensions 是 Gradle Android Plugin 提供的“多维度风味”机制，用于把业务属性正交拆分。步骤如下：

1. 在 android 块内先声明维度列表并指定顺序，例如
   flavorDimensions "channel", "api"
   表示 channel 维度优先级高于 api。
2. 为每个维度定义具体 flavor：
   productFlavors {
   huawei { dimension "channel" }
   xiaomi { dimension "channel" }
   oss { dimension "api" }
   aws { dimension "api" }
   }
   Gradle 会自动生成 huaweiOss、huaweiAws、xiaomiOss、xiaomiAws 四个 BuildVariant。
3. 冲突解决：
   a) 资源冲突——在对应 flavor 的 res/values 里重新定义同名资源，高优先级维度会覆盖低优先级；
   b) Manifest 冲突——使用 tools:node="remove" 或 manifestPlaceholders 在维度风味里动态替换；
   c) 依赖冲突——在 flavor 下用 implementation("$dep") { exclude group: 'com.android.support' }，或通过 matchingFallbacks 让缺失维度自动降级；
   d) 代码冲突——若两个 flavor 出现同包同类，可在 main 中抽取接口，各 flavor 提供不同实现，或通过 sourceSets 把冲突类放到独立目录，在 CI 脚本里用 pickFirst 打包仅保留一份。
4. 验证：执行 ./gradlew assembleHuaweiOssRelease，观察 Build->APK 内容，确认 META-INF、lib、res 均符合预期；再用 diff 工具对比 huaweiOss 与 xiaomiAws 的 AndroidManifest.xml 与 R.java，确保差异化生效且无冗余。

通过以上方法，可在 1 个 module 内维护 3×4×2=24 个渠道包，而 build.gradle 仅保留 3+4+2=9 段描述，极大降低合并冲突与人力成本。

拓展思考

1. 如果未来新增“付费模式”维度，但老版本 CI 脚本只识别两个维度，如何做到零停机热插拔？
   答：在 gradle.properties 中定义维度白名单，CI 读取后动态注入 -Pandroid.injected.invoked.from.ide=false，老任务忽略新维度，新任务全量回归，实现灰度切换。
2. 国内厂商要求 64 位与 32 位分包，而海外需要统一 fat-aab，如何与维度共存？
   答：把 abi 作为隐藏维度，利用 splits.abi.enable + bundle.abi.enable 交叉开关，在 assemble 阶段过滤，上传 Play 时统一，上传国内商店时按渠道维度自动拆包。
3. 维度组合数爆炸导致 Gradle Configuration 阶段 30 s+，如何进一步优化？
   答：
   • 使用 gradle 7.6 的 TYPESAFE_PROJECT_ACCESSORS，减少字符串匹配；
   • 开启 configuration cache 与 parallel；
   • 对非关键维度采用 composite build 拆仓库，CI 按需聚合，实现“子维度秒级编译、主维度小时级回归”。