前言：这不是一个关于如何在一个Android应用中使用构建类型和产品口味的问题。我理解其中涉及的基本概念。这个问题更多的是试图理解在构建类型中应该指定哪个配置，在产品风味中应该指定哪个配置，以及实际上是否有必要进行任何区分。
本周，我学习了更多关于Android应用程序的分级配置。我最初认为自己对构建类型和产品风格有很好的把握，但我对文档越深入，就越意识到这两者之间的区别对我来说根本不清楚。
既然有一个定义良好的层次结构（在构建类型中指定的属性优先于产品口味中指定的属性的意义上），我就不明白为什么根本就需要区分构建类型和产品口味。将所有属性和方法合并到产品风味DSL对象中，然后仅仅将构建类型作为（默认）风味维度来处理，这不是更好吗？
一些导致我困惑的具体例子：
>
SigningConfig属性可以在生成类型和产品风味中设置...但是minifyenabled（我假设是shrinkresources？）只能在生成类型中配置。
applicationid只能在产品风味中指定...和applicationidsuffix只能在生成类型中指定！？
实际问题：
给出了上面的例子：构建类型与产品风格之间的角色有明确的区别吗？
如果是的话，最好的理解方法是什么？
如果不是，是否计划最终将构建类型和产品风格合并到单个可配置的DSL对象中？
扩展@CommonSware在评论中所说的内容，其基本思想是构建类型用于应用程序的不同构建，而这些构建在功能上并不不同--如果您有应用程序的调试和发布版本，它们是同一个应用程序，但其中一个包含调试代码，可能更多的日志记录等，而另一个是精简和优化的，可能通过ProGuard进行混淆。在口味方面，我们的目的是让应用程序在某些方面有明显的不同。最明显的例子是应用程序的免费版本和付费版本，但开发人员也可能会根据应用程序的分发地点进行区分（这可能会影响应用程序内计费API的使用）。
开发人员会为不同的客户制作很多很多不同版本的类似应用程序--一个例子可能是一个简单的应用程序，它在web视图中打开一个网页，每个版本都有不同的URL和品牌--这是一个很好的使用口味的方法。
重申一下，如果它是“同一个应用程序”，取一些对最终用户不重要的差异，特别是如果除了一个外所有的变体都是供您自己测试和开发使用的，并且只有一个变体将部署给最终用户，那么它是构建类型的一个很好的候选者。如果它是一个“不同的”应用程序，并且会向用户部署多个变体，那么它可能是一个产品风格的候选。
您已经看到了构建类型和风格之间存在一些功能上的差异，其中一种支持某些选项，而另一种则不支持。但是这些概念是不同的，尽管它们是相似的，而且没有计划将它们合并在一起。
