为什么构建类型与产品风味不同？答案

【问题标题】：Why are build types distinct from product flavors?为什么构建类型与产品风味不同？
【发布时间】：2015-01-12 15:56:25
【问题描述】：

前言：这不是关于如何在 Android 应用中使用构建类型和产品风格的问题。我了解所涉及的基本概念。这个问题更多是关于尝试了解应该在构建类型中指定哪些配置，应该在产品风格中指定哪些配置，以及是否真的需要任何区别。

本周，我一直在学习有关 Android 应用的 gradle 配置的更多信息。我最初认为我对构建类型和产品风格有很好的处理，但我越深入文档，我就越意识到两者之间的区别对我来说根本不清楚。

由于存在明确定义的层次结构（在某种意义上，构建类型中指定的属性优先于产品风格中指定的属性），我不明白为什么需要区分构建类型和产品风格全部。将所有属性和方法合并到产品风味 DSL 对象中，然后将构建类型视为（默认）风味维度不是更好吗？

一些导致我困惑的具体例子：

signingConfig 属性可以在构建类型和产品风格中设置...但minifyEnabled（我假设是shrinkResources？）只能在构建类型中配置。
applicationId 只能在产品风味中指定...而applicationIdSuffix 只能在构建类型中指定！？

实际问题：

鉴于上述示例：构建类型与产品风格的角色之间是否有明显区别？

如果是这样，最好的理解方法是什么？

如果没有，是否计划最终将构建类型和产品风格合并到一个可配置的 DSL 对象中？

【问题讨论】：

“应该在构建类型中指定哪些配置，应该在产品风格中指定哪些配置”——构建类型模拟您的开发生命周期（调试、“dogfood”、发布等）。产品风格为您的分销策略建模（Google IAP vs. Amazon IAP vs. BlackBerry IAP 等）。这些是独立的概念。至于其余的，我认为与实施相关的技术原因决定了他们如何设置 DSL，因此如果有合并计划，我会感到惊讶。
@CommonsWare 在高层次上很有意义。是的，例如，类型/风味的顺序处理可能会限制人们更改整个applicationId 的方式和时间。

标签： android android-gradle-plugin

【解决方案1】：

扩展 @CommonsWare 在 cmets 中所说的内容，基本思想是构建类型适用于功能上没有不同的应用程序的不同构建 - 如果您有应用程序的调试和发布版本，它们是同一个应用程序，但一个包含调试代码，可能还有更多日志记录等，另一个经过简化和优化，可能通过 ProGuard 进行了混淆。使用风味，目的是应用程序在某些方面明显不同。最明显的例子是您的应用程序的免费版本和付费版本，但开发人员也可能会根据分发位置进行区分（这可能会影响应用内结算 API 的使用）。

有些开发人员为不同的客户制作了许多不同版本的类似应用程序——例如，一个简单的应用程序可以在网络视图中打开一个网页，每个版本都有不同的 URL 和品牌——这是对风味的一种很好的利用。

重申一下，如果它是“相同的应用程序”，请取模一些对最终用户并不重要的差异，特别是如果除一个之外的所有变体都用于您自己的测试和开发用途并且只有一个变体将部署到最终用户，那么它是构建类型的良好候选者。如果它是“不同的”应用程序并且将向用户部署多个变体，那么它可能是产品风格的候选者。

您已经看到构建类型和风格之间存在一些功能差异，其中一种支持某些选项，而另一种则不支持。但即使它们相似，概念也不同，并且没有将它们合并在一起的计划。

【讨论】：

谢谢，斯科特。我绝对认为这种区别是有道理的（“构建类型”和“产品风味”的名称适合这种用法）。或许可以将applicationId 的问题理解为：由于flavors 代表了你的应用程序的“完全不同”的版本，因此能够指定“完全”不同的应用程序ID 是有意义的；而对于固定风格，多个构建类型都代表“相同”的应用程序，因此只允许更改应用程序 ID 后缀（从而保留应用程序 ID 的“分组”）。

【解决方案2】：

构建类型配置我们应用的包装：

shrinkResources
proguardFile
等

Product Flavors配置不同的类和资源：

在 Flavor1 中，您的 MainActivity 可以做一些事情，而在 Flavor2 中它可以有不同的实现
不同的应用名称
等

每种产品风味都可以有自己的以下属性值，其中包括基于defaultConfig 中的相同属性：

applicationId
minSdkVersion
targetSdkVersion
versionCode
versionName

【讨论】：

附注：product flavour + build type == build variant

【解决方案3】：

以下是我将差异提炼为本质的方法：

buildType 是构建的方式。
flavor 是构建的内容。

【讨论】：

【解决方案4】：

build types 用于指示具有不同证书的debug/release 模式并启用Proguard 或debuggable 标志。

flavors 用于具有自定义功能（例如免费或付费版本）、minimum and target API 级别、设备和 API 要求，例如 layout、drawable，因此您可以在不同的环境中拥有不同的代码和资源flavors.

【讨论】：

【解决方案5】：

两者都是您的应用程序的重要组成部分，我们必须使用构建类型和产品风格来提供不同的规则和法规

两者都在 build.gradle(Module) 中定义 #Build_Type 其中主要有调试和发布

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            buildConfigField "boolean", "FILE_LOGGING", "true"
            signingConfig signingConfigs.debug
            versionNameSuffix ".debug"
        }
    }

在上述构建类型中，我们可以提供一套不同的调试和发布规则

#Product_Flavors 这取决于您的环境，例如舞台、质量保证或生产环境

productFlavors {
       staging {
            versionNameSuffix "_STG"
            versionCode 12
            dimension "version"
            buildConfigField "boolean", "shareLog", "true"
            applicationIdSuffix ".staging.abcapp"
            
      }
        QA {
            versionNameSuffix "_awsQA"
            versionCode 01
            dimension "version"
            buildConfigField "boolean", "shareLog", "true"
            applicationIdSuffix ".awsqa.abcapp"
       
        }
        production {
            dimension "version"
            buildConfigField "boolean", "shareLog", "false"
            applicationIdSuffix ".android.abc"
            
        }
    }

使用它你可以设置你的 pkg 名称，你也可以指定环境

您可以从构建变体中更改此构建类型和产品风格

【讨论】：

【解决方案6】：

让我们用一个真实的例子来说明。假设你有一个煮熟的面条盘。所以如果你问厨师那

它的构建类型是什么？

他/她会这样回答-

用半开水
盐少
在压力锅等中

这意味着她/他正在描述她/他如何制作面条。

它的生产风味是什么？ 他/她会这样回答-

俗气
少咸
不油腻

这意味着他/她正在描述构建后的风味。

我们来theory-

构建类型： 允许您创建和修改构建配置。默认情况下，每个模块都有调试和发布构建类型，但您可以根据需要定义更多。

Flavors： 允许您创建多个构建风格，其中每个风格指定一组配置设置，例如模块的minimum 和target SDK version，以及version code 和version name .例如，您可以定义一个最小 SDK 为 15 且目标 SDK 为 21 的风格，以及另一种风格的最小 SDK 为 19 且目标 SDK 为 23。

【讨论】：