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

Question

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

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

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

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

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

实际问题：

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

如果是这样，理解它的最佳方式是什么？

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

Answer 1

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

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

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

您已经看到构建类型和风格之间存在一些功能差异，其中一种支持某些选项，而另一种不支持。但概念虽然相似但不同，目前还没有合并的计划。

Answer 2

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

shrinkResources
proguardFile
等等

产品风味配置不同类和资源：

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

每种产品口味都可以有自己的以下属性值，这些属性基于 defaultConfig 中的相同属性：

applicationId
minSdkVersion
targetSdkVersion
versionCode
versionName

Answer 3

以下是我如何从本质上提炼差异：

buildType 是构建的如何。
flavor 是构建的什么。

Answer 4

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

flavors 用于具有自定义功能（例如免费或付费版本）、minimum and target API 级别、设备和 API 要求，如 layout、drawable 所以你可以在不同的 flavors.

中拥有不同的代码和资源

Answer 5

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

两者都在build.gradle（模块）中定义 #Build_Type 其中主要有debugging和release

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 这取决于您的环境，例如阶段、质量保证或生产

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

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

Answer 6

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

它的构建类型是什么？

s/he会这样回答-

半开水
少盐
高压锅等

这意味着 s/he 描述了如何 s/he 构建面条。

它的生产口味是什么？ s/he会这样回答-

俗气
少咸
少油

这意味着 s/he 正在描述构建后 flavor 现在的实际情况。

让我们来到theory-

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

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

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

Why are build types distinct from product flavors?

android

android-gradle-plugin