Question

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

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

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

导致我混淆的一些具体例子：

可以在构建类型和产品风格中设置signingConfig属性...但minifyEnabled（我认为，shrinkResources？）只能在构建类型。
applicationId只能在产品口味中指定...... applicationIdSuffix只能在构建类型中指定！

实际问题：

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

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

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

Answer 1

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

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

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

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

Answer 2

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

shrinkResources
progaurdFile
等

风味配置不同的类和资源。

你的MainActivity可以做些什么，而在Flavor2中有不同的实现
不同的应用名称
等

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

applicationId
minSdkVersion
targetSdkVersion
versionCode
versionName

Answer 3

这是我将差异精炼为本质的方法：

buildType是构建的方式。
flavor是构建的内容。

Answer 4

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

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

Answer 5

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

两者都在 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"
        }
    }

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

#Product_Flavors 这取决于你的环境，如舞台、质量保证或生产

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名称也可以指定环境

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

Answer 6

让我们用一个真实的例子来澄清。假设你有一个煮熟的面条盘。所以如果你问厨师

它的构建类型是什么？

他/她会这样回答-

用半开水
少盐
在压力锅等中

这意味着他/他正在描述他/他如何制作面条。

它的生产风味是什么？ 他/她会这样回答-

俗气
不太咸
少油

这意味着他/她正在描述构建后的风味。

让我们来到theory -

构建类型：允许您创建和修改构建配置。默认情况下，每个模块都有调试和发布构建类型，但您可以根据需要定义更多。

Flavors： 允许您创建多个构建风格，其中每个风格指定一组配置设置，例如模块的 minimum 和 target SDK version，以及 {{1 }} 和 version code。例如，您可以定义一种最小 SDK 为 15 且目标 SDK 为 21 的风味，以及另一种最小 SDK 为 19 且目标 SDK 为 23 的风味。

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

6 个答案: