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