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

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

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

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

一些引起我困惑的具体例子：

• signingConfig可以在构建类型和产品风格中设置该属性...但是minifyEnabled（我假设，shrinkResources？）只能在构建类型中进行配置。

• applicationId只能在产品口味中指定...并且applicationIdSuffix只能在构建类型中指定！

实际问题：

在上述示例的基础上：构建类型与产品风味的作用之间是否有明显的区别？

如果是这样，了解它的最佳方法是什么？

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

扩展@CommonsWare在评论中所说的内容，基本思想是构建类型是针对应用程序的不同内部版本的，它们在功能上没有不同-如果您具有应用程序的调试和发行版本，则它们是同一应用程序，但其中一个包含调试代码，可能包含更多日志记录，等等，而另一个则通过ProGuard进行了优化和优化，甚至可能被混淆。带有风味的目的是，该应用在某种程度上与众不同。最明显的例子是您的应用程序的免费版与付费版，但是开发人员还可以根据其分发位置进行区分（这可能会影响应用程序内计费API的使用）。

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

重申一下，如果它是“相同的应用程序”，则对一些对最终用户不重要的差异进行模运算，尤其是如果除一个以外的所有变体都供您自己的测试和开发使用，并且仅将一个变体部署到最终用户，那么它是构建类型的理想选择。如果它是“一个不同的”应用程序，并且将多个变体部署到用户，那么它可能是一种产品风格的候选者。

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

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

• shrinkResources
• proguardFile
• 等等

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

• 在Flavor1中，您的MainActivity可以执行某些操作，而在Flavor2中，它可以具有不同的实现
• 不同的应用名称
• 等等

每种产品香料都可以具有以下属性的值，这些属性基于以下属性相同defaultConfig：

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

这是我将差异精简为本质的方法：

• buildType是如何构建的。
• flavor是什么样的身材。

将build types用于指示debug/release与不同的证书和启用模式Proguard或debuggable标志。

将flavors用于定制功能（例如免费或付费版），minimum and target API喜欢的水平，设备和API的要求layout，drawable这样你就可以在不同的不同的代码和资源flavors。