让我们看一个真实的例子。 假设你有一个煮好的面条盘。如果你问厨师这个问题

它的构建类型是什么?

他/她会这样回答-

用半开的水 少放盐 在高压锅等。

这意味着他/她在描述他/她是如何做面条的。

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

干酪 不咸的 更少的油

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

让我们来看看理论

构建类型:在Android应用程序中，构建类型通常指的是你运行应用程序的环境。每个模块默认情况下都必须调试和发布构建类型，但你可以根据需要定义更多的构建类型。如果你在科技公司工作过，你可能知道通常不止这两家。您可以自定义您的构建类型，以包括其他风格，如QA，发布候选或RC, Pre-Prod，或任何适合您的需求。

风格:除了基于环境的差异之外，应用程序通常也会有所不同。口味支持这种变化。例如，你可以使用口味来处理:

选择付费版本还是免费版本。 为你上传的每个商店(游戏邦注:如亚马逊Appstore、谷歌Play store和三星Galaxy store)提供相应版本。 为不同的产品使用相同的应用程序，并自定义资产以改变应用程序的外观和感觉。

构建变体:变体是构建类型和构建风格的组合。例如，你可以拥有应用的“开发付费”版本，这是应用的“开发”构建类型和“付费”风格的结合。如果你同时拥有这两种风格和类型，你可以在上传到谷歌Play Store或任何其他商店时发布变体。

让我们看一个真实的例子。 假设你有一个煮好的面条盘。如果你问厨师这个问题

它的构建类型是什么?

他/她会这样回答-

用半开的水 少放盐 在高压锅等。

这意味着他/她在描述他/她是如何做面条的。

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

干酪 不咸的 更少的油

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

让我们来看看理论

构建类型:在Android应用程序中，构建类型通常指的是你运行应用程序的环境。每个模块默认情况下都必须调试和发布构建类型，但你可以根据需要定义更多的构建类型。如果你在科技公司工作过，你可能知道通常不止这两家。您可以自定义您的构建类型，以包括其他风格，如QA，发布候选或RC, Pre-Prod，或任何适合您的需求。

风格:除了基于环境的差异之外，应用程序通常也会有所不同。口味支持这种变化。例如，你可以使用口味来处理:

选择付费版本还是免费版本。 为你上传的每个商店(游戏邦注:如亚马逊Appstore、谷歌Play store和三星Galaxy store)提供相应版本。 为不同的产品使用相同的应用程序，并自定义资产以改变应用程序的外观和感觉。

构建变体:变体是构建类型和构建风格的组合。例如，你可以拥有应用的“开发付费”版本，这是应用的“开发”构建类型和“付费”风格的结合。如果你同时拥有这两种风格和类型，你可以在上传到谷歌Play Store或任何其他商店时发布变体。

Expanding on what @CommonsWare said in the comments, the basic idea is that build types are for different builds of your application that aren't functionally different -- if you have a debug and release version of your app, they're the same app, but one contains debugging code, maybe more logging, etc., and the other is streamlined and optimized and possibly obfuscated via ProGuard. With flavors, the intent is that the app is notably different in some way. The clearest example would be a free vs. a paid version of your app, but developers may also differentiate based on where it's being distributed (which could affect in-app billing API use).

有些开发者为不同的用户制作了许多不同版本的类似应用——例如，一个简单的应用在网页视图中打开一个网页，每个版本都有不同的url和品牌——这是一个很好的使用风格的例子。

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

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

构建类型配置我们的应用程序的包装:

shrinkResources proguardFile 等。

产品类型配置不同的类和资源:

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

每种产品风格都可以有自己的以下属性值，这些属性是基于defaultConfig中的相同属性的:

applicationId minSdkVersion targetSdkVersion versionCode versionName

以下是我如何从本质上提炼出两者的区别:

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_Flavours 这取决于你所处的环境，如阶段，qa或制作

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名称，你也可以指定环境

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