blocks|key|2715872|text|扩展@CommonsWare在评论中所说的，基本思想是构建类型用于不同版本的应用程序，它们在功能上没有什么不同--如果你有一个应用程序的调试版和发行版，它们是相同的应用程序，但一个包含调试代码，可能会有更多日志记录等，而另一个是简化和优化的，并可能通过ProGuard进行混淆。对于口味，其意图是应用程序在某些方面明显不同。最明显的例子是你的应用程序的免费版本和付费版本，但开发人员也可能根据应用程序的分发位置进行区分(这可能会影响应用程序内计费API的使用)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2715873|有些开发人员为不同的客户开发了许多不同版本的类似应用程序--举个例子，一个简单的应用程序可以在网页视图中打开一个网页，每个版本有不同的URL和品牌--这是对风格的很好的利用。|2715874|重申一下，如果它是“相同的应用程序”，模化一些对最终用户不重要的差异，特别是如果除了一个之外的所有变体都用于您自己的测试和开发，并且只有一个变体将被部署到最终用户，那么它是一个很好的构建类型的候选者。如果它是一个“不同的”应用程序，并且将为用户部署多个变体，那么它可能是一种产品风格的候选者。|2715875|您已经看到，构建类型和风格之间存在一些功能差异，因为其中一种类型支持某些选项，而另一种则不支持。尽管它们很相似，但它们的概念是不同的，并且没有计划将它们合并在一起。|2715876|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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).

There are developers that make many, many different versions of a similar app for different customers -- an example might be a simple app that opens up a web page in a web view, with different URLs and branding for each version -- this is a good use of flavors.

To reiterate, if it's "the same application", modulo some differences that aren't important to the end user, and especially if all of the variants except for one are for your own testing and development use and only one variant will be deployed to end users, then it's a good candidate for build types. If it's "a different" application and multiple variants would be deployed to users, then perhaps it's a candidate for a product flavor.

You've already seen that there are some functionality differences between build types and flavors, in that some options are supported for one but not the other. But the concepts are different even though they're similar, and there's no plan to merge them together.

blocks|key|141819|text|构建类型配置我们的应用程序的打包：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|141820|141821|shrinkResources|unordered-list-item|CODE|141822|proguardFile|141823|etc.|141824|141825|产品风格配置不同的类和资源：|141826|141827|在Flavor1中可以做一些事情，而在Flavor2中可以有不同的implementation|141828|different应用程序name|141829|141830|141831|每种产品风格都可以有自己的以下属性的值，这些属性基于defaultConfig中的相同属性|141832|141833|applicationId|141834|minSdkVersion|141835|targetSdkVersion|141836|versionCode|141837|versionName|141838|141839|entityMap^0|0|4|0|0|0|F|0|0|C|0|0|0|0|4|0|0|0|0|0|0|Q|D|0|0|0|D|0|0|D|0|0|G|0|0|B|0|0|B|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1I|8|@$9|1J|A|1K|B|J]]|D|@]|E|$]]|$1|K|3|L|5|I|7|1L|8|@$9|1M|A|1N|B|J]]|D|@]|E|$]]|$1|M|3|N|5|I|7|1O|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]|$1|S|3|T|5|I|7|1U|8|@]|D|@]|E|$]]|$1|U|3|V|5|I|7|1V|8|@]|D|@]|E|$]]|$1|W|3|N|5|I|7|1W|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1Y|8|@$9|1Z|A|20|B|J]]|D|@]|E|$]]|$1|10|3|-4|5|6|7|21|8|@]|D|@]|E|$]]|$1|11|3|12|5|I|7|22|8|@$9|23|A|24|B|J]]|D|@]|E|$]]|$1|13|3|14|5|I|7|25|8|@$9|26|A|27|B|J]]|D|@]|E|$]]|$1|15|3|16|5|I|7|28|8|@$9|29|A|2A|B|J]]|D|@]|E|$]]|$1|17|3|18|5|I|7|2B|8|@$9|2C|A|2D|B|J]]|D|@]|E|$]]|$1|19|3|1A|5|I|7|2E|8|@$9|2F|A|2G|B|J]]|D|@]|E|$]]|$1|1B|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]|$1|1C|3|-4|5|6|7|2I|8|@]|D|@]|E|$]]]|1D|$]]

Build Types configure the packaging of our app:
<ul>
<li><code>shrinkResources</code></li>
<li><code>proguardFile</code></li>
<li>etc.</li>
</ul>
Product Flavors configure different classes and resources:
<ul>
<li>in Flavor1 your MainActivity can do something, while in Flavor2 it can have a different implementation</li>
<li>different app name</li>
<li>etc.</li>
</ul>
Each product flavor can have its own values of the following properties, among others, which are based on the same properties from <code>defaultConfig</code>:
<ul>
<li><code>applicationId</code></li>
<li><code>minSdkVersion</code></li>
<li><code>targetSdkVersion</code></li>
<li><code>versionCode</code></li>
<li><code>versionName</code></li>
</ul>

blocks|key|2928675|text|下面是我如何提炼出本质上的区别：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2928676|2928677|buildType+is+the+how+of+the+build.|unordered-list-item|offset|length|style|CODE|BOLD|2928678|flavor+is+the++of+the+build。|2928679|2928680|entityMap^0|0|0|0|9|H|3|0|0|6|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|R|8|@$F|S|G|T|H|I]|$F|U|G|V|H|J]]|9|@]|A|$]]|$1|K|3|L|5|E|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|O|$]]

Here's how I distill the difference down to its essence:

<ul>
<li><code>buildType</code> is the how of the build.</li>
<li><code>flavor</code> is the what of the build.</li>
</ul>

blocks|key|2928705|text|build+types用于指示具有不同证书和启用Proguard或debuggable标志debug/release模式。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2928706|flavors用于自定义功能(例如免费或付费版本)、minimum+and+target+API级别、设备和layout、drawable等应用程序接口要求，因此您可以在不同的flavors中使用不同的代码和资源。|2928707|entityMap^0|0|B|O|8|X|A|19|D|0|0|7|Q|M|1I|6|1P|8|2G|7|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$]]

The <code>build types</code> are used to indicate <code>debug/release</code> mode with different certificates and enabling <code>Proguard</code> or <code>debuggable</code> flag. 

The <code>flavors</code> are used to have custom features (for example free or paid version), <code>minimum and target API</code> levels, device and API requirements like the <code>layout</code>, <code>drawable</code> so you can have different code and resources in different <code>flavors</code>.

blocks|key|2928715|text|两者都是您的应用程序的基本部分，我们必须使用构建类型和产品风格提供不同的规则和规则|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2928716|它们都是在build.gradle(模块)+#Build_Type中定义的，主要有已调试和已发布|2928717|buildTypes+{
++++++++release+{
++++++++++++minifyEnabled+false
++++++++++++proguardFiles+getDefaultProguardFile('proguard-android-optimize.txt'),+'proguard-rules.pro'
++++++++}
++++++++debug+{
++++++++++++buildConfigField+"boolean",+"FILE_LOGGING",+"true"
++++++++++++signingConfig+signingConfigs.debug
++++++++++++versionNameSuffix+".debug"
++++++++}
++++}|code-block|syntax|javascript|2928718|在上面的构建类型中，我们可以为调试和发布提供一组不同的规则|2928719|#Product_Flavours它取决于您的环境，如阶段、qa或生产|2928720|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"
++++++++++++
++++++++}
++++}|2928721|使用此选项，您可以设置pkg名称，也可以指定环境|2928722|这个构建类型和产品风格，您可以从build+variants中选择|offset|length|style|BOLD|2928723|entityMap^0|0|0|0|0|0|0|0|0|U|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|13|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@$S|16|T|17|U|V]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Both are the essential part of your application in which we have to provide different rules and regulation using build types and product flavors
Both are defined in build.gradle(Module)
#Build_Type
Which mainly have debugged and release
<pre><code>buildTypes {
 release {
 minifyEnabled false
 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
 }
 debug {
 buildConfigField &quot;boolean&quot;, &quot;FILE_LOGGING&quot;, &quot;true&quot;
 signingConfig signingConfigs.debug
 versionNameSuffix &quot;.debug&quot;
 }
 }
</code></pre>
In the above build types, we can provide a different set of rules for debugging and release
#Product_Flavours
It depend upon your enviorment like stage,qa or producation
<pre><code>productFlavors {
 staging {
 versionNameSuffix &quot;_STG&quot;
 versionCode 12
 dimension &quot;version&quot;
 buildConfigField &quot;boolean&quot;, &quot;shareLog&quot;, &quot;true&quot;
 applicationIdSuffix &quot;.staging.abcapp&quot;
 
 }
 QA {
 versionNameSuffix &quot;_awsQA&quot;
 versionCode 01
 dimension &quot;version&quot;
 buildConfigField &quot;boolean&quot;, &quot;shareLog&quot;, &quot;true&quot;
 applicationIdSuffix &quot;.awsqa.abcapp&quot;
 
 }
 production {
 dimension &quot;version&quot;
 buildConfigField &quot;boolean&quot;, &quot;shareLog&quot;, &quot;false&quot;
 applicationIdSuffix &quot;.android.abc&quot;
 
 }
 }
</code></pre>
Using this you can set your pkg name also u can specify the environment
This build types and product flavours you can chagne from build variants

blocks|key|143000|text|让我们用一个真实的例子来说明一下。假设你有一个煮好的面条盘。所以如果你问厨师|type|unstyled|depth|inlineStyleRanges|entityRanges|data|143001|它的构建类型是什么？|offset|length|style|BOLD|143002|他/她会这样回答-|143003|143004|加半开水|unordered-list-item|143005|加少盐|143006|放入高压锅等。|143007|143008|这意味着他/她正在描述他/他如何构建面条。|143009|​|143010|📷|atomic|143011|143012|它的生产风格是什么？s/他会这样回答-|143013|143014|Cheesy|143015|Less+salty|143016|Less+oily|143017|+(减少油污)|143018|这意味着他/她正在描述构建之后风格中的实际内容。|143019|143020|143021|143022|让我们来看看theory+-|143023|构建类型：允许您创建和修改构建配置。默认情况下，每个模块都有调试和发布构建类型，但您可以根据需要定义更多类型。|143024|风格：允许您创建多种构建风格，其中每种风格都指定了一组配置设置，比如模块的minimum和target+SDK+version，以及version+code和version+name。例如，您可能定义了一种最低SDK为15、目标SDK为21的风格，以及另一种SDK最低为19、目标SDK为23的风格。|CODE|143025|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/1a683da312cfef424491e3db92cc3201.jpeg|imageAlt|1|https://ask.qcloudimg.com/http-save/yehe-900000/aae4a635bc3996ac91911d85ff0bdeb0.jpeg|2|LINK|MUTABLE|url|https://developer.android.com/studio/projects^0|0|0|A|0|0|0|0|0|0|0|0|0|0|1|0|0|0|0|A|0|0|0|0|0|0|F|2|0|0|0|1|1|0|0|6|6|2|0|0|5|0|0|3|11|7|19|I|1U|C|27|C|0^^$0|@$1|2|3|4|5|6|7|23|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|24|8|@$D|25|E|26|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|27|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|29|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|2A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|2B|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|2D|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2E|8|@]|9|@]|A|$]]|$1|W|3|X|5|Y|7|2F|8|@]|9|@$D|2G|E|2H|1|2I]]|A|$]]|$1|Z|3|V|5|6|7|2J|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2K|8|@$D|2L|E|2M|F|G]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|2N|8|@]|9|@]|A|$]]|$1|13|3|14|5|M|7|2O|8|@]|9|@]|A|$]]|$1|15|3|16|5|M|7|2P|8|@]|9|@]|A|$]]|$1|17|3|18|5|M|7|2Q|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2R|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2S|8|@$D|2T|E|2U|F|G]]|9|@]|A|$]]|$1|1D|3|V|5|6|7|2V|8|@]|9|@]|A|$]]|$1|1E|3|X|5|Y|7|2W|8|@]|9|@$D|2X|E|2Y|1|2Z]]|A|$]]|$1|1F|3|V|5|6|7|30|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|31|8|@]|9|@$D|32|E|33|1|34]]|A|$]]|$1|1I|3|1J|5|6|7|35|8|@$D|36|E|37|F|G]]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|38|8|@$D|39|E|3A|F|G]|$D|3B|E|3C|F|1M]|$D|3D|E|3E|F|1M]|$D|3F|E|3G|F|1M]|$D|3H|E|3I|F|1M]]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|3J|8|@]|9|@]|A|$]]]|1O|$1P|$5|1Q|1R|1S|A|$1T|1U|1V|-4]]|1W|$5|1Q|1R|1S|A|$1T|1X|1V|-4]]|1Y|$5|1Z|1R|20|A|$21|22]]]]

Let's clear with a real life example.
Suppose you have a cooked noodles plate. So if you ask the chef that
What is the Build type of it?
s/he will answer like this -
<ul>
<li>With half boiled water</li>
<li>With less salt</li>
<li>In pressure cooker etc.</li>
</ul>
That means s/he is describing how s/he build the noodles.
<a href="https://i.stack.imgur.com/PPYgTm.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/PPYgTm.png" alt="enter image description here" /></a>
What is the Production Flavors of it?
s/he will answer like this -
<ul>
<li>Cheesy</li>
<li>Less salty</li>
<li>Less oily</li>
</ul>
That means s/he is describing what actually now it is in flavor after the build.
<a href="https://i.stack.imgur.com/D38crm.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/D38crm.jpg" alt="enter image description here" /></a>
Let's come to the <a href="https://developer.android.com/studio/projects" rel="nofollow noreferrer">theory</a> -
Build Types: Lets you create and modify build configurations. By default, every module has debug and release build types, but you can define more as needed.
Flavors: Lets you create multiple build flavors, where each flavor specifies a set of configuration settings, such as the module's <code>minimum</code> and <code>target SDK version</code>, and the <code>version code</code> and <code>version name</code>. For example, you might define one flavor that has a minimum SDK of 15 and a target SDK of 21, and another flavor that has a minimum SDK of 19 and a target SDK of 23.

Preface: this is not a question about how to use build types and product flavors in an Android app. I understand the basic concepts involved. This question is more about trying to understand which configuration should be specified in a build type, which configuration should be specified in a product flavor, and whether any distinction is actually necessary.

This week, I've been learning more about gradle configuration for Android apps. I initially thought I had a good handle on build types vs product flavors, but the deeper I got into the documentation the more I realized the distinction between the two was not clear to me at all.

Since there is a well-defined hierarchy (in the sense that properties specified in build types take precedence over those specified in product flavors), I don't understand why there is a need to distinguish between build types and product flavors at all. Would it not be better to merge all properties and methods into the product flavor DSL object, and then just treat build type as a (default) flavor dimension?

Some concrete examples that led to my confusion:

<ul>
<li>The <code>signingConfig</code> property can be set in both build types and product flavors... but <code>minifyEnabled</code> (and, I assume, <code>shrinkResources</code>?) can only be configured in build types.</li>
<li><code>applicationId</code> can only be specified in product flavors... and <code>applicationIdSuffix</code> can only be specified in build types!?</li>
</ul>

The actual question(s):

Given the above examples: is there a clear distinction between the roles of build types vs product flavors?

If so, what is the best way to understand it?

If not, is the plan to eventually merge build types and product flavors into a single configurable DSL object?

Why are build types distinct from product flavors?

前言:这不是一个关于如何在Android应用程序中使用构建类型和产品风格的问题。我理解所涉及的基本概念。这个问题更多地是关于试图理解应该在构建类型中指定哪些配置，应该在产品风格中指定哪些配置，以及是否有必要进行任何区分。这周，我学习了更多关于Android应用的gradle配置。我最初认为我对构建类型和产品风格有很好的...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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