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

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

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

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

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

---

构建类型配置我们应用程序的打包：

收缩资源

proguard文件

等等

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

在 Flavor1 你的 MainActivity 可以做一些事情，而在 Flavor2 它可以有不同的实现

不同的应用名称

等等

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

应用程序 ID

minSdkVersion

目标SDK版本

版本代码

版本名称

---

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

buildType 是构建的方式。

风味是构建的内容。

---

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

两者都是在 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 名称也可以指定环境

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

---

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

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

---

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

它的构建类型是什么？

她/他会这样回答——

用半开水

少盐

在压力锅等。

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

https://i.stack.imgur.com/PPYgTm.png

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

俗气

少咸

少油腻

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

https://i.stack.imgur.com/D38crm.jpg

让我们来到theory -

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

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

---