先搞明白一件事为什么需要它假设你做了个 App现在老板提了一堆要求要出一个免费版和一个付费版免费版带广告付费版没广告要上华为、小米、应用宝好几个应用商店每个渠道包要能统计各自的下载量开发时连测试服务器上线时连正式服务器别搞混了新手的第一反应可能是那我复制几份代码工程呗一个工程改一处。这想法立刻就崩——你有 5 个渠道 × 2 个版本 10 份工程改一个 bug 要改 10 遍发一次版要打包 10 次改到你怀疑人生。Product Flavors产品风味就是来解决这个问题的一套代码产出多个不同的 App。你只维护一份代码通过配置告诉 Gradle我要出哪些版本剩下的它帮你自动组合打包。先分清两个容易搞混的概念Android 构建里有两个词长得像特别容易混Build Type和Product Flavor。**Build Type构建类型**管的是怎么构建——主要是 debug 和 releasedebug带调试信息、不混淆、能连电脑调试给开发用release混淆、压缩、签名给用户用的正式包**Product Flavor产品风味**管的是构建成什么——比如免费版还是付费版、哪个渠道。这两个是两个维度会互相组合。假设你有 free/paid 两个 flavor配上 debug/release 两个 build type最终会产出freeDebug 免费版-调试包 freeRelease 免费版-正式包 paidDebug 付费版-调试包 paidRelease 付费版-正式包2 个 flavor × 2 个 build type 4 个变体Variant。这个变体就是最终能打出来的包。记住这个乘法关系后面配置就好理解了。上手最基础的配置在模块的build.gradleapp 目录下那个里写android{// ... 其他配置flavorDimensionsversion// 定义一个维度先别管下面细说productFlavors{free{dimensionversionapplicationIdcom.example.app.free// 免费版包名versionName1.0-free}paid{dimensionversionapplicationIdcom.example.app.paid// 付费版包名versionName1.0-paid}}}这段配置定义了两个 flavorfree 和 paid。重点看几个字段applicationId——这是最有用的功能之一。它让免费版和付费版有不同的包名意味着两个 App 可以同时装在一台手机上互不冲突。用户可以先装免费版体验再装付费版。versionName——版本名可以每个 flavor 不一样方便区分。那个flavorDimensions是干嘛的上面出现了个flavorDimensions version很多人第一次看懵。它叫风味维度。前面说 flavor 是一个维度但实际项目里你可能同时有好几个维度要组合。举个真实例子你既要区分免费/付费又要区分渠道华为/小米。这就是两个维度android{// 声明两个维度注意顺序前面的优先级高flavorDimensionsversion,channelproductFlavors{// 第一个维度版本free{dimensionversion}paid{dimensionversion}// 第二个维度渠道huawei{dimensionchannel}xiaomi{dimensionchannel}}}现在 Gradle 会把两个维度交叉组合免费版 × 华为 freeHuawei 免费版 × 小米 freeXiaomi 付费版 × 华为 paidHuawei 付费版 × 小米 paidXiaomi再乘上 debug/release 两个 build type2个version × 2个channel × 2个buildType 8 个变体所以flavorDimensions就是告诉 Gradle“我有几个维度它们要互相交叉组合。”每个 flavor 必须用dimension声明自己属于哪个维度否则 Gradle 会报错这是很多人踩的第一个坑忘了写 dimension或者维度名写错。维度声明的顺序还决定了优先级和命名顺序——flavorDimensions version, channel里 version 在前所以生成的名字是freeHuaweiversion 在前channel 在后。flavor 之间怎么区分代码和资源光有不同包名还不够。免费版要显示广告、付费版不显示界面上免费版和付费版字样也不一样。这些差异怎么实现Android 提供了一套目录约定。除了主代码目录src/main你可以为每个 flavor 建专属目录src/ ├── main/ ← 公共代码和资源所有版本共享 │ ├── java/ │ └── res/ ├── free/ ← 只有免费版会用到 │ ├── java/ │ └── res/ └── paid/ ← 只有付费版会用到 ├── java/ └── res/编译免费版时Gradle 会把mainfree的内容合并编译付费版时合并mainpaid。free 目录里的东西付费版根本看不到反之亦然。比如你可以在 free 和 paid 目录里各放一个同名的字符串资源!-- src/free/res/values/strings.xml --stringnameapp_name超级App免费版/string!-- src/paid/res/values/strings.xml --stringnameapp_name超级App专业版/string编译哪个版本就用哪个版本的名字。同名资源flavor 目录会覆盖 main 目录这是最常用的定制手段。用 BuildConfig 传递配置差异有时候差异不是资源而是逻辑开关——比如要不要显示广告、“连哪个服务器”。这种用buildConfigField最方便productFlavors{free{dimensionversionbuildConfigFieldboolean,SHOW_ADS,truebuildConfigFieldString,API_URL,\https://test.example.com\}paid{dimensionversionbuildConfigFieldboolean,SHOW_ADS,falsebuildConfigFieldString,API_URL,\https://api.example.com\}}编译后Gradle 会自动生成一个BuildConfig类里面就有这些字段。代码里直接用if(BuildConfig.SHOW_ADS){showAd();// 只有免费版会走进来}// 请求接口时用对应的地址Api.setBaseUrl(BuildConfig.API_URL);同一份代码编译成不同 flavor 时BuildConfig.SHOW_ADS的值不一样行为就不一样。这就完美实现了一套代码多种行为而且是编译期就定死的运行时零判断开销。渠道打包的经典用法回到最开始老板的需求之一——多渠道统计。传统做法是给每个渠道包塞一个渠道标识用manifestPlaceholders往 AndroidManifest 里注入productFlavors{huawei{dimensionchannelmanifestPlaceholders[CHANNEL_NAME:huawei]}xiaomi{dimensionchannelmanifestPlaceholders[CHANNEL_NAME:xiaomi]}}在 AndroidManifest.xml 里用占位符接收meta-dataandroid:nameCHANNELandroid:value${CHANNEL_NAME}/打华为包时${CHANNEL_NAME}就被替换成 “huawei”打小米包就是 “xiaomi”。App 运行时读出这个值上报给统计后台就能知道用户是从哪个渠道来的。补一句如果渠道特别多几十上百个用 flavor 打包会非常慢每个都要完整编译一遍。这种情况业界一般用美团的 Walle 等方案直接在已打好的包里写渠道信息不重新编译。flavor 方案适合渠道不多、且各渠道确实有代码/资源差异的场景。怎么打包配置好后Android Studio 的 Build Variants 面板里能直接切换选哪个变体。命令行则用 Gradle 任务命名规则是assemble 变体名./gradlew assembleFreeRelease# 打免费版正式包./gradlew assemblePaidDebug# 打付费版调试包./gradlew assembleFreeHuaweiRelease# 免费版华为渠道正式包./gradlew assembleRelease# 一口气打出所有 release 变体变体名就是各维度名字 build type 拼起来的首字母大写。这套命名规则记住了打包命令随手就能写。几个容易踩的坑忘写 dimension。只要用了flavorDimensions每个 flavor 就必须声明dimension漏一个直接编译报错。这是新手最常见的错误。变体数量爆炸。维度和 flavor 一多变体数量是乘法增长的2×3×2 就是 12 个了。不是所有组合都需要可以用variantFilter过滤掉不需要的组合别让构建列表里塞满你根本不打的包。flavor 目录别和 main 放重复的东西。同名 Java 类如果 main 和 flavor 目录里都有会冲突报错资源是覆盖代码是冲突规则不一样。正确做法是某个类如果各 flavor 实现不同就只放在各 flavor 目录、main 里不放公共的才放 main。applicationId 和包名package别搞混。applicationId是应用的唯一标识决定能否共存、上架标识代码里的 package 是代码组织结构两者可以不一样。flavor 改的是 applicationId。一句话收尾Product Flavors 的核心思想一套代码通过维度 风味的配置组合产出多个不同的 App 变体。用flavorDimensions声明有哪些维度要交叉用productFlavors定义每个具体风味用专属目录、BuildConfig、manifestPlaceholders来实现各版本之间的差异。说白了它和我们前面聊的数据与逻辑分离是同一个味道——把变化的部分渠道、版本、环境抽出来做成配置把不变的部分业务代码留在 main 里共享。一处改动全线生效再也不用维护十几份工程了。