为什么构buildtypes不同于产品口味？
前言：这不是一个关于如何在Android应用程序中使用构buildtypes和产品风格的问题。 我理解所涉及的基本概念。 这个问题更多的是试图了解哪些configuration应该在构buildtypes中指定，哪些configuration应该在产品风格中指定，以及是否有必要进行区分。
本周，我一直在学习更多关于Android应用程序的gradleconfiguration。 我最初以为自己对构buildtypes和产品风格有了很好的处理，但是我越深入到文档中，我越发现两者之间的区别对我来说根本不清楚。
由于有一个定义明确的层次结构（从构buildtypes中指定的属性优先于产品风格中指定的属性），我不明白为什么需要区分构buildtypes和产品风格。 将所有属性和方法合并到产品风格的DSL对象中，然后将构buildtypes视为（默认）风格维度，会不会更好？
一些导致我混乱的具体例子：
-
可以在构buildtypes和产品风格中设置
signingConfig属性…但是minifyEnabled（和，我假设shrinkResources？）只能在构buildtypes中configuration。 -
applicationId只能在产品口味中指定…和applicationIdSuffix只能在构buildtypes中指定！
实际的问题 ：
鉴于上面的例子：构buildtypes与产品风格的作用是否有明显的区别？
如果是的话，了解它的最好方法是什么？
如果没有，最终是否将构buildtypes和产品风格合并到单个可configuration的DSL对象中？
扩展@CommonsWare在评论中所说的基本思想是，构buildtypes是针对应用程序的不同构build，这些构build在function上是不同的 – 如果您有应用程序的debugging版本和发行版本，则它们是相同的应用程序，但其中一个包含debugging代码，也许更多的日志logging等，另一个是精简和优化，可能通过ProGuard混淆。 随着口味，意图是应用程序在某种程度上是显着不同的。 最明显的例子是应用程序的免费版本和付费版本，但开发人员也可能根据其分发位置（可能影响应用程序内API开支）进行区分。
有开发人员为不同的客户制作了许多类似的应用程序的不同版本 – 例如，可能是一个简单的应用程序，在Web视图中打开一个网页，每个版本都有不同的URL和品牌标识 – 这是一个很好的使用口味。
重申一下，如果它是“同一个应用程序”，那么对一些对最终用户来说不重要的差异进行模块化，特别是除了一个以外的所有变体都是为了您自己的testing和开发使用而只有一个变体将被部署到最终用户，那么这是一个很好的候选人的build设types。 如果这是一个“不同的”应用程序，并将多个变体部署到用户，那么也许这是一个产品风味的候选人。
您已经看到，构buildtypes和风格之间存在一些function差异，一些选项是支持的，而不是其他的。 但是即使它们是相似的概念也是不同的，并且没有计划将它们合并在一起。
buildTypeconfiguration我们如何打包我们的应用程序
- shrinkResources
- progaurdFile
- 等等
风味configuration不同的类和资源。
-
在Flavor1中你的MainActivity可以做些什么，而在Flavor2中有不同的实现
-
不同的应用程序名称
-
等等
每种产品的风味都可以有自己的以下属性值，其中包括与defaultConfig相同的属性：
-
applicationId -
minSdkVersion -
targetSdkVersion -
versionCode -
versionName
