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

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

本周，我学习了更多关于Android应用的gradle配置。我最初认为我已经很好地处理了构建类型和产品风格，但随着文档的深入，我意识到两者之间的区别对我来说根本不清楚。

由于存在定义良好的层次结构(在构建类型中指定的属性优先于产品类型中指定的属性)，我不理解为什么需要区分构建类型和产品类型。将所有属性和方法合并到产品风格DSL对象中，然后仅仅将构建类型作为(默认的)风格维度不是更好吗?

以下是一些让我困惑的具体例子:

  • signingConfig属性可以在构建类型和产品风格中设置…但是minifyEnabled(和，我假设，shrinkResources?)只能在构建类型中配置。

  • applicationId只能在产品风味中指定…和applicationIdSuffix只能在构建类型中指定!?

实际问题:

对于上面的例子:构建类型和产品风格之间的角色是否有明确的区别?

如果是，最好的理解方式是什么?

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

27060 次浏览
小开
最佳答案

扩展@CommonsWare在评论中所说的，基本的想法是，构建类型是针对应用程序的不同构建的，它们在功能上没有区别——如果你有一个应用程序的调试版本和发布版本，它们是同一个应用程序，但一个包含调试代码，可能有更多的日志记录，等等，另一个是精简和优化的，可能通过ProGuard混淆。风味的目的是应用程序在某些方面明显不同。最明显的例子就是应用的免费版和付费版，但开发者也可能根据应用的发行地点进行区分(这可能会影响应用内计费API的使用)。

有些开发者为不同的用户制作了许多不同版本的类似应用——例如，一个简单的应用在网页视图中打开一个网页，每个版本都有不同的url和品牌——这是一个很好的使用风格的例子。

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

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

小开

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

  • shrinkResources
  • proguardFile
  • 等。

产品口味配置不同的类和资源:

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

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

  • applicationId
  • minSdkVersion
  • targetSdkVersion
  • versionCode
  • versionName
小开

以下是我如何从本质上提炼出两者的区别:

  • buildType是构建的如何。
  • flavor是构建的什么。
小开

build types用于指示具有不同证书的debug/release模式，并启用Proguard或debuggable标志。

flavors用于具有自定义功能(例如免费或付费版本)，minimum and target API级别，设备和API需求，如layout， drawable，因此您可以在不同的flavors中拥有不同的代码和资源。

小开

两者都是应用程序的重要组成部分，我们必须使用构建类型和产品风格提供不同的规则和管理

两者都在build.gradle(Module)中定义 # Build_Type 其中主要有调试和发布

buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
buildConfigField "boolean", "FILE_LOGGING", "true"
signingConfig signingConfigs.debug
versionNameSuffix ".debug"
}
}

在上面的构建类型中，我们可以为调试和发布提供一组不同的规则

< p > # Product_Flavours 这取决于你的环境，如阶段，qa或生产

productFlavors {
staging {
versionNameSuffix "_STG"
versionCode 12
dimension "version"
buildConfigField "boolean", "shareLog", "true"
applicationIdSuffix ".staging.abcapp"
            

}
QA {
versionNameSuffix "_awsQA"
versionCode 01
dimension "version"
buildConfigField "boolean", "shareLog", "true"
applicationIdSuffix ".awsqa.abcapp"
       

}
production {
dimension "version"
buildConfigField "boolean", "shareLog", "false"
applicationIdSuffix ".android.abc"
            

}
}

使用这个你可以设置你的pkg名称，你也可以指定环境

您可以从构建变体中更改此构建类型和产品风味

小开
让我们看一个真实的例子。 假设你有一个煮好的面条盘。如果你问厨师

它的构建类型是什么?

他/她会这样回答-

  • 用半开的水
  • 少放盐
  • 在高压锅等。

这意味着她/他正在描述她/他如何构建面条。

enter image description here

它的生产风味是什么? S /he会这样回答-

  • 干酪
  • 不咸的
  • 更少的油

这意味着s/他正在描述构建后味道中的实际内容。

enter image description here

让我们来看看理论 -

构建类型:在Android应用程序中，构建类型通常指的是你运行应用程序的环境。默认情况下，每个模块都必须调试和释放构建类型，但你可以根据需要定义更多。如果你在科技公司工作过，你可能知道通常不止这两家。您可以自定义您的构建类型，以包括其他风格，如QA，发布候选或RC, Pre-Prod，或任何适合您的需求。

除了基于环境的差异之外，应用程序通常在某些方面有所不同。口味支持这种变化。例如，你可以使用口味来处理:

  • 选择付费版本还是免费版本。
  • 为你上传的每个商店(游戏邦注:如亚马逊Appstore、谷歌Play store和三星Galaxy store)提供相应版本。
  • 为不同的产品使用相同的应用程序，并自定义资产以改变应用程序的外观和感觉。

构建变体:变体是构建类型和构建风格的组合。例如，你可以拥有应用的“开发付费”版本，这是应用的“开发”构建类型和“付费”风格的结合。如果你同时拥有这两种风格和类型，你可以在上传到谷歌Play Store或任何其他商店时发布变体。


提交答案