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

Question

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

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

由于有一个定义良好的层次结构（从构建类型中指定的属性优先于产品风格中指定的属性），我不明白为什么需要区分构建类型和产品口味在所有。将所有属性和方法合并到产品风格DSL对象中，然后将构建类型作为（默认）风格维度对待会不会更好？

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

• 的signingConfig属性可以在两种类型的建设和产品的口味......但minifyEnabled（？而且，我认为，shrinkResources）设置只能是在构建类型中配置。

• applicationId只能在产品口味中指定......而applicationIdSuffix只能在生成类型中指定！？

的实际问题（S）：

在上述的例子：有构建类型的产品VS口味的角色之间有明显的区别？

如果是这样，理解它的最好方法是什么？

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

Answer 1

扩展@CommonsWare在评论中所说的内容，其基本思想是，构建类型适用于应用程序的不同构建，这些构建在功能上并不不同 - 如果您有应用程序的调试和发布版本，重新使用相同的应用程序，但其中一个包含调试代码，可能还有更多日志记录等，另一个应用程序经过简化和优化，并可能通过ProGuard进行混淆。随着口味，意图是应用程序在某种程度上是明显不同的。最明显的例子是免费或付费版本的应用程序，但开发人员也可能根据其分发位置（这可能会影响应用内API帐户使用）进行区分。

有开发人员为不同的客户制作了许多类似应用程序的不同版本 - 例如，可能是一个简单的应用程序，它在Web视图中打开网页，并为每个版本提供不同的URL和品牌信息 - - 这是一种很好用的口味。

重申一下，如果它是“同一个应用程序”，模块化一些对最终用户并不重要的差异，尤其是如果除一个之外的所有变体都用于您自己的测试和开发使用，并且只有一个变体将被部署到最终用户，那么它是构建类型的一个很好的候选人。如果它是“不同的”应用程序，并且多个变体将被部署给用户，那么它可能是产品风格的候选者。

您已经看到，构建类型和风格之间存在一些功能差异，因为一些选项支持一种，而另一种则不支持。但即使它们相似，概念也是不同的，并且没有计划将它们合并在一起。

Answer 2

buildType配置如何打包我们的应用程序

• shrinkResources
• progaurdFile
• 等

味配置不同的类和资源。

• 在Flavor1您的MainActivity可以做一些事情，并在Flavor2不同的实施

• differente应用程序名称

• 等

每个产品的风味可以有自己的价值观以下属性，其中包括基于与defaultConfig相同的属性：

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName