引言:这不是一个关于如何在Android应用程序中使用构建类型和产品风格的问题。我了解其中的基本概念。这个问题更多的是试图理解应该在构建类型中指定哪个配置，应该在产品类型中指定哪个配置，以及是否确实有必要进行任何区分。
本周，我学习了更多关于Android应用的gradle配置。我最初认为我已经很好地处理了构建类型和产品风格，但随着文档的深入，我意识到两者之间的区别对我来说根本不清楚。
由于存在定义良好的层次结构(在构建类型中指定的属性优先于产品类型中指定的属性)，我不理解为什么需要区分构建类型和产品类型。将所有属性和方法合并到产品风格DSL对象中，然后仅仅将构建类型作为(默认的)风格维度不是更好吗?
以下是一些让我困惑的具体例子:
signingConfig属性可以在构建类型和产品风格中设置…但是minifyEnabled(我假设还有shrinkResources?)只能在构建类型中配置。
applicationId只能在产品口味中指定…和applicationIdSuffix只能在构建类型中指定!?
实际问题:
对于上面的例子:构建类型和产品风格之间的角色是否有明确的区别?
如果是，最好的理解方式是什么?
如果不是，是否计划最终将构建类型和产品风格合并到一个可配置的DSL对象中?
两者都是应用程序的重要组成部分，我们必须使用构建类型和产品风格提供不同的规则和管理
两者都在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_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名称，你也可以指定环境
您可以从构建变体中更改此构建类型和产品风味
Expanding on what @CommonsWare said in the comments, the basic idea is that build types are for different builds of your application that aren't functionally different -- if you have a debug and release version of your app, they're the same app, but one contains debugging code, maybe more logging, etc., and the other is streamlined and optimized and possibly obfuscated via ProGuard. With flavors, the intent is that the app is notably different in some way. The clearest example would be a free vs. a paid version of your app, but developers may also differentiate based on where it's being distributed (which could affect in-app billing API use).
有些开发者为不同的用户制作了许多不同版本的类似应用——例如，一个简单的应用在网页视图中打开一个网页，每个版本都有不同的url和品牌——这是一个很好的使用风格的例子。
重申一下，如果它是“相同的应用程序”，对一些对最终用户不重要的差异取模，特别是如果除了一个变体以外的所有变体都是为您自己的测试和开发使用，并且只有一个变体将部署给最终用户，那么它是构建类型的一个很好的候选者。如果它是一个“不同的”应用程序，并且将为用户部署多个变体，那么它可能是一个产品风格的候选。
您已经看到构建类型和风格之间存在一些功能差异，其中一些选项只支持其中一种，而不支持另一种。但是，尽管它们很相似，但它们的概念是不同的，而且没有计划将它们合并在一起。
两者都是应用程序的重要组成部分，我们必须使用构建类型和产品风格提供不同的规则和管理
两者都在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_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名称，你也可以指定环境
您可以从构建变体中更改此构建类型和产品风味
