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

Question

前言:这不是关于如何在Android应用程序中使用构建类型和产品风格的问题.我理解所涉及的基本概念.这个问题更多的是试图了解应该在构建类型中指定哪个配置,应该在产品风格中指定哪个配置,以及是否实际需要区分.

本周,我一直在了解有关Android应用程序的gradle配置的更多信息.我最初认为我对构建类型和产品口味有很好的处理,但是我越深入到文档中,我就越发现两者之间的区别对我来说根本不清楚.

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

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

• 该signingConfig属性可以设置两种类型的建设和产品的口味......但minifyEnabled(和,我想,shrinkResources？)只能在构建类型进行配置.

• applicationId只能在产品风格中指定...并且applicationIdSuffix只能在构建类型中指定!？

实际问题:

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

如果是这样,了解它的最佳方法是什么？

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

Answer 1

扩展了@CommonsWare在评论中所说的内容,基本思想是构建类型适用于不同功能不同的应用程序版本 - 如果你有应用程序的调试和发布版本,它们就是同一个应用程序,但其中一个包含调试代码,可能包含更多日志记录等,另一个包含简化和优化,并可能通过ProGuard进行模糊处理.有了味道,意图是应用程序在某种程度上显着不同.最明显的例子是您的应用程序的免费版本和付费版本,但开发人员也可能根据其分发位置进行区分(这可能会影响应用内的计费API使用).

有些开发人员为不同的客户制作了许多不同版本的类似应用程序 - 例如,一个简单的应用程序可以在Web视图中打开一个网页,每个版本都有不同的URL和品牌 - 这是一个好吃的味道.

重申一下,如果它是"相同的应用程序",则模拟一些对最终用户不重要的差异,特别是如果除了一个变量之外的所有变体都用于您自己的测试和开发用途,并且只会部署一个变体最终用户,那么它是构建类型的一个很好的候选者.如果它是"不同的"应用程序并且会向用户部署多个变体,那么它可能是产品风格的候选者.

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

Answer 2

buildType配置我们打包应用程序的方式

• shrinkResources
• progaurdFile
• 等等

Flavor配置不同的类和资源.

• 在Flavor1中你的MainActivity可以做些什么,而在Flavor2中可以做不同的实现

• differente应用程序名称

• 等等

每种产品风味都可以具有以下属性的值,这些属性基于以下相同的属性defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Answer 3

以下是我将差异精简为本质的方法：

• buildType是如何构建的。
• flavor是什么样的身材。