为什么构建类型与产品风格不同？

Question

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

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

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

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

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

• applicationId 只能在产品口味中指定…和 applicationIdSuffix 只能在构建类型中指定！？

实际问题：

鉴于以上示例：构建类型与产品风格的角色之间是否存在明显区别？

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

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

原文由 stkent 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

扩展@CommonsWare 在评论中所说的内容，基本思想是构建类型适用于功能上没有差异的应用程序的不同构建——如果您有应用程序的调试版本和发布版本，它们就是同一个应用程序，但其中一个包含调试代码，可能还有更多日志记录等，另一个经过简化和优化，并可能通过 ProGuard 进行了混淆处理。使用 flavors 的目的是让应用程序在某些方面明显不同。最明显的例子是你的应用程序的免费版本和付费版本，但开发人员也可能根据它的分发位置来区分（这可能会影响应用程序内结算 API 的使用）。

有些开发人员为不同的客户制作了很多很多不同版本的类似应用程序——一个例子可能是一个简单的应用程序，它在网络视图中打开一个网页，每个版本都有不同的 URL 和品牌——这是很好地利用口味。

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

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

原文由 Scott Barta 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

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

• shrinkResources
• proguardFile
• 等等

Product Flavors 配置不同的类和资源：

• 在 Flavor1 中，您的 MainActivity 可以做一些事情，而在 Flavor2 中，它可以有不同的实现
• 不同的应用名称
• 等等

每种产品口味都可以有自己的以下属性值，这些属性基于 defaultConfig 中的相同属性：

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

原文由 itzhar 发布，翻译遵循 CC BY-SA 4.0 许可协议