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

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (18)

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

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

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

一些导致我混乱的具体例子:

  • signingConfig属性可以在构建类型和产品风格中进行设置......但是minifyEnabled(以及我假设的shrinkResources?)只能在构建类型中进行配置。
  • applicationId只能在产品口味中指定...并且applicationIdSuffix只能在构建类型中指定!?

实际问题

鉴于上述例子:构建类型与产品口味的角色之间是否存在明显的区别?

如果是这样,理解它的最好方法是什么?

如果没有,是否最终将构建类型和产品风格合并到单个可配置的DSL对象中?

提问于
用户回答回答于

基本思想是构建类型针对应用程序的不同构建,这些构建在功能上并不不同 - 如果您有应用程序的调试和发布版本,则它们是相同的应用程序,但其中一个包含调试代码,可能还有更多日志记录等,另一个则通过简化和优化,并可能通过ProGuard进行混淆。随着口味,意图是应用程序在某种程度上是明显不同的。最明显的例子是免费与付费版本的应用程序,但开发人员也可能根据其分发位置(这可能会影响应用内API帐户使用)进行区分。

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

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

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

用户回答回答于

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

  • shrinkResources
  • progaurdFile
  • 等等

配置不同的类和资源。

  • 在Flavor1中,你的MainActivity可以做一些事情,并且在Flavor2中有不同的实现
  • 不同的App名称
  • 等等

每种产品口味可以具有其自身的以下属性值,其中,其基于来自以下属性的相同属性defaultConfig

  • applicationId
  • minSdkVersion
  • targetSdkVersion
  • versionCode
  • versionName

扫码关注云+社区