关键词：
当你在开发一个app,通常你会有几个版本。大多数情况是你需要一个开发版本，用来测试app和弄清它的质量，然后还需要一个生产版本。这些版本通常有不同的设置，例如不同的URL地址。更可能的是你可能需要一个免费版和收费版本。基于上述情况，你需要处理不同的版本：开发免费版，开发付费版本，生产免费版，生产付费版，而针对不同的版本不同的配置，这极大增加的管理难度。
Gradle有一些方便的方法来管理这些问题。我们很早之前谈过debug和release版本，现在我们谈到另外一个概念，不同的产品版本。构建版本和生产版本通常可以合并，构建版本和生产版本的合并版叫做构建变种。
这一章我们将学习构建版本，它能使得开发更有效率，并且学习如何使用它们。然后我们会讨论构建版本和生产版本的不同，以及如何将其合并。我们会探讨签名机制，如何针对不同的变种签名等。
在这一章，我们遵循如下规则：
- Build types
- Product flavors
- Build variants
- Signing configurations
构建版本
在Gradle的Android插件中，一个构建版本意味着定义一个app或者依赖库如何被构建。每个构建版本都要特殊的一面，比如是否需要debug，application id是什么，是否不需要的资源被删除等等。你可以定义一个构建版本通过buildTypes方法。例如：
android {
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile
(‘proguard-android.txt‘), ‘proguard-rules.pro‘
}
}
}
这个文件定义了该模块是release版本，然后定义了proguard的位置。该release版本不是唯一的构建版本，默认情况下，还有个debug版本。Android studio把它视为默认构建版本。
创建自己的构建版本
当默认的构建版本不够用的时候，创建版本也是很容易的一件事，创建构建版本你只需要在buildTypes写入自己的版本。如下所示：
android {
buildTypes {
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
buildConfigField "String", "API_URL",
"/"http://staging.example.com/api/""
}
}
}
我们定义了一个staging版本，该版本定义了一个新的application id，这让其与debug和release版本的applicationID不同。假设你使用了默认的配置，那么applicationID将会是这样的：
- Debug: com.package
- Release: com.package
- Staging: com.package.staging
这意味着你可以在你的设备上安装staging版本和release版本。staging版本也有自己的版本号。buildConfigField定义了一个新的URL地址。你不必事事都去创建，所以最可能的方式是去继承已有的版本。
android {
buildTypes {
staging.initWith(buildTypes.debug)
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
debuggable = false
}
}
}
initWith()方法创建了一个新的版本的同时，复制所有存在的构建版本，类似继承。我们也可以复写该存在版本的所有属性。
Source sets
当你创建了一个新的构建版本，Gradle也创建了新的source set。默认情况下，该文件夹不会自动为你创建，所有你需要手工创建。
app
└── src
├── debug
│ ├── java
│ │ └── com.package
│ │
│ ├── res
│ │ └── layout
│ │ └── activity_main.xml
│ └── AndroidManifest.xml
├── main
│ ├── java
│ │ └── com.package
│ │
│ ├── res
└── MainActivity.java
└── Constants.java
│ │
│ │
│ │
│ └── AndroidManifest.xml
├── staging
│ ├── java
│ │ └── com.package
├── drawable
└── layout
└── activity_main.xml
│ │
│ ├── res
│ │ └── layout
│ │ └── activity_main.xml
│ └── AndroidManifest.xml
└── release
├── java
│ └── com.package
│ └── Constants.java
└── AndroidManifest.xml
注意：当你添加一个Java类的时候，你需要知道以下过程，当你添加了CustomLogic.java到staging版本，你可以添加相同的类到debug和release版本，但是不能添加到main版本。如果你添加了，会抛出异常。
当使用不同的source sets的时候，资源文件的处理需要特殊的方式。Drawables和layout文件将会复写在main中的重名文件，但是values文件下的资源不会。gradle将会把这些资源连同main里面的资源一起合并。
举个例子，当你在main中创建了一个srings.xml的时候：
<resources>
<string name="app_name">TypesAndFlavors</string>
<string name="hello_world">Hello world!</string>
</resources>
当你在你的staing版本也添加了rings.xml：
<resources>
<string name="app_name">TypesAndFlavors STAGING</string>
</resources>
然后合并的strings.xml将会是这样的：
<resources>
<string name="app_name">TypesAndFlavors STAGING</string>
<string name="hello_world">Hello world!</string>
</resources>
当你创建一个新的构建版本而不是staging，最终的strings.xml将会是main目录下的strings.xml。
manifest也和value文件下的文件一样。如果你为你的构建版本创建了一个manifest文件，那么你不必要去拷贝在main文件下的manifest文件，你需要做的是添加标签。Android插件将会为你合并它们。
我们将在会之后的章节讲到合并的更多细节。
依赖包
每一个构建版本都有自己的依赖包，gradle自动为每一个构建的版本创建不同的依赖配置。如果你想为debug版本添加一个logging框架，你可以这么做：
dependencies {
compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])
compile ‘com.android.support:appcompat-v7:22.2.0‘
debugCompile ‘de.mindpipe.android:android-logging-log4j:1.0.3‘
}
你可以结合不同的构建版本着不同的构建配置，就像这种方式，这让你的不同版本的不同依赖包成为可能。
product flavors
和构建版本不同，product flavors用来为一个app创建不同版本。典型的例子是，一个app有付费和免费版。product flavors极大简化了基于相同的代码构建不同版本的app。
如果你不确定你是否需要一个新的构建版本或者product flavors，你应该问你自己，你是否需要内部使用和外部使用的apk。如果你需要一个完全新的app去发布，和之前的版本完全隔离开，那么你需要product flavors。否则你只是需要构建版本。
创建product flavors
创建product flavors非常的容易。你可以在productFlavors中添加代码：
android {
productFlavors {
red {
applicationId ‘com.gradleforandroid.red‘
versionCode 3
}
blue {
applicationId ‘com.gradleforandroid.blue‘
minSdkVersion 14
versionCode 4
}
}
}
product flavors和构建版本的配置不同。因为product flavors有自己的ProductFlavor类，就像defaultConfig，这意味着你的所有productFlavors都分享一样的属性。
Source sets
就像构建版本一样，product Flavors也有自己的代码文件夹。创建一个特殊的版本就像创建一个文件夹那么简单。举个例子，当你有的生产版本的blue flavors有一个不同的app图标，该文件夹需要被叫做blueRelease。
多个flavors构建变体
在一些例子中，你可能需要创建一些product flavors的合并版本。举个例子，client A和client B可能都想要一个free和paid的版本，而他们又都是基于一样的代码，但是有不一样的颜色等。创建四个不同的flavors意味着有重复的配置。合并flavors最简单的做法可能是使用flavor dimensions，就像这样：
android {
flavorDimensions "color", "price"
productFlavors {
red {
flavorDimension "color"
}
blue {
flavorDimension "color"
}
free {
flavorDimension "price"
}
paid {
flavorDimension "price"
}
}
}
当你添加了flavor dimensions，你就需要为每个flavor添加flavorDimension，否则会提示错误。flavorDimensions定义了不同的dimensions，当然其顺序也很重要。当你合并二个不同的flavors时，他们可能有一样的配置和资源。例如上例：
- blueFreeDebug and blueFreeRelease
- bluePaidDebug and bluePaidRelease
- redFreeDebug and redFreeRelease
- redPaidDebug and redPaidRelease
构建变体
构建变体是构建版本和生产版本的结合体。当你创建了一个构建版本或者生产版本，同样的，新的变体也会被创建。举个例子，当你有debug和release版本，你创建了red和blue的生产版本，那么变体将会有四个：
你可以在Android studio的左下角找到它，或者通过VIEW|Tool Windows|Build Variants打开它。该视图列出了所有的变体，并且允许你去切换它们。改变他们将会影响到你按Run按钮。
如果你没有product flavors，那么变体只是简单的包含构建版本，就算你没有定义任何构建版本，Android studio也会默认为你创建debug版本的。
tasks
android插件回味每一个变体创建不同的配置。一个新的Android项目会有debug和release版本，所有你可以使用assembleDebug和assembleRelease，当然当你使用assemble命令，会二者都执行。当你添加了一个新的构建版本，新的task也会被创建。例如：
- assembleBlue uses the blue flavor configuration and assembles both BlueRelease and BlueDebug.
- assembleBlueDebug combines the flavor configuration with the build type configuration, and the flavor settings override the build type settings.
Source sets
构建变体也可以有自己的资源文件夹，举个例子，你可以有src/blueFreeDebug/java/。
资源文件和manifest的合并
在打包app之前，Android插件会合并main中的代码和构建的代码。当然，依赖项目也可以提供额外的资源，它们也会被合并。你可能需要额外的Android权限针对debug变体。举个例子，你不想在main中申明这个权限，因为这可能导致一些问题，所以你可以添加一个额外的mainfest文件在debug的文件夹中，申明额外的权限。
资源和mainfests的优先级是这样的：
如果一个资源在main中和在flavor中定义了，那么那个在flavor中的资源有更高的优先级。这样那个在flavor文件夹中的资源将会被打包到apk。而在依赖项目申明的资源总是拥有最低优先级。
创建构建变体
gradle让处理构建变体变得容易。
android {
buildTypes {
debug {
buildConfigField "String", "API_URL",
"/"http://test.example.com/api/""
}
staging.initWith(android.buildTypes.debug)
staging {
buildConfigField "String", "API_URL",
"/"http://staging.example.com/api/""
applicationIdSuffix ".staging"
}
}
productFlavors {
red {
applicationId "com.gradleforandroid.red"
resValue "color", "flavor_color", "#ff0000"
}
blue {
applicationId "com.gradleforandroid.blue"
resValue "color", "flavor_color", "#0000ff"
}
}
}
在这个例子中，我们创建了4个变体，分别是blueDebug，blueStaging，redDebug，redStaging。每一个变体都有其不同的api url以及颜色。例如：
变体过滤器
忽略某个变体也是可行的。这样你可以加速你的构建当使用assemble的时候，这样你列出的tasks将不会执行那么你不需要的变体。你可以使用过滤器，在build.gradle中添加代码如下所示：
android.variantFilter { variant ->
if(variant.buildType.name.equals(‘release‘)) {
variant.getFlavors().each() { flavor ->
if (flavor.name.equals(‘blue‘)) { variant.setIgnore(true);
}
}
}
}
在这个例子中，我们检查下：
你可以看到blueFreeRelease和bluePaidRelease被排除在外，如果你运行gradlew tasks，你会发现所有的关于上述变体的tasks不再存在。
签名配置
在你发布你的应用之前，你需要为你的app私钥签名。如果你有付费版和免费版，你需要有不同的key去签名不同的变体。这就是配置签名的好处。配置签名可以这样定义：
android {
signingConfigs {
staging.initWith(signingConfigs.debug)
release {
storeFile file("release.keystore")
storePassword"secretpassword"
keyAlias "gradleforandroid"
keyPassword "secretpassword"
}
}
}
在这个例子中，我们创建了2个不同的签名配置。debug配置是as默认的，其使用了公共的keystore和password，所以没有必要为debug版本创建签名配置了。staging配置使用了initWith()方法，其会复制其他的签名配置。这意味着staging和debug的key是一样的。
release配置使用了storeFile，定义了key alias和密码。当然这不是一个好的选择，你需要在 Gradle properties文件中配置。
当你定义了签名配置后，你需要应用它们。构建版本都有一个属性叫做signingConfig，你可以这么干：
android {
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}
上例使用了buildTypes，但是你可能需要对每个版本生成不同的验证，你可以这么定义：
android {
productFlavors {
blue {
signingConfig signingConfigs.release
}
}
}
当然，你在flavor中定义这些，最好会被重写，所以最好的做法是：
android {
buildTypes {
release {
productFlavors.red.signingConfig signingConfigs.red
productFlavors.blue.signingConfig signingConfigs.blue
}
}
}
总结
在这一章，我们讨论了构建版本和生产版本，以及如何结合它们。这将会是非常有用的工具，当你需要不同的url以及不同的keys，而你们有相同的代码和资源文件，但是有不同的类型以及版本，构建版本和生产版本将会让你的生活更美好。
我们也谈论了签名配置以及如何使用他们。
下一章，你将会学习到多模块构建，因为当你想把你的代码分成一个依赖包或者依赖项目的时候，或者你想把Android wear模块放在你的应用的时候，这将非常重要。
构建之法读后感第四篇
使用软件的人叫做用户。那么，想要编出一个好软件，就必须要清楚的知道自己的用户是什么样的。于是乎，典型用户和典型场景的分析就变得尤为重要。那么，怎么定义典型用户呢？定义典型用户的模板可以包括以下内容... 查看详情
转载gradleforandroid第六篇(测试)
由于现阶段Android开发趋于敏捷开发，再加上国内大大小小的互联网公司都在做app，导致很多这会是一个系列，所以如果你看完这篇文章，请看下列文章：开发人员对单元测试没有基本的概念，但是本篇博文不会为大家讲解什么... 查看详情
接口测试（java+testng+ant+jenkins）第四篇jenkins
1、jenkins是什么？ 是基于Java开发的一种持续集成工具，用于监控持续重复的工作。2、下载安装 http://www.cnblogs.com/zh-96/p/6445118.html3、新建任务 4、任务配置增加构建步骤lnvokeAnt内容： 保存 5、运行 项目... 查看详情
elasticsearch查询第四篇：匹配查询（match）
匹配（Match）查询属于全文（Fulltext）查询，不同于词条查询，ElasticSearch引擎在处理全文搜索时，首先分析（analyze）查询字符串，然后根据分词构建查询，最终返回查询结果。匹配查询共有三种类型，分别是布尔（boolean）、短... 查看详情
第四篇：模块与包
第四篇：模块与包 PYTHON-模块定义搜索路径PYTHON-包相对导入&绝对导入 查看详情
pytorch学习笔记第四篇——神经网络(代码片段)
上一章已经了解了自动梯度Autograd，pytorch中可以使用torch.nn构建神经网络，nn依赖于autograd来定义模型并对其进行微分。nn.Module包含层，以及返回output的方法forward(input)。文章目录1.定义网络1.1自定义网络1.2使用自定义... 查看详情
数据结构第四篇——线性表的链式存储之双向链表
?注：未经博主同意，不得转载。 前面讨论的单链表，每个结点中只有一个指针域，用来存放指向后继结点的指针，因此，从某个结点出发只能顺时针往后查找其他结点。若要查找某个结点的直接前驱，则需要从头指针开始... 查看详情
开始写游戏---第四篇
开始写游戏---第四篇 今天完成了商店的物品展示功能。 写了一个物品展示面板组件： 这是代码： 使用的时候这么使用： 额。。。感觉使用有点麻烦，我又提供了... 查看详情
spring第四篇
在spring第三篇中介绍了bean元素属性在第四篇中介绍spring注入的方式 1set方法注入 建立一个User类创建私有的属性set get方法 重写toString方法代码如下：packagebean;publicclassUser{ privateStringname; privateintage; publicStringgetN... 查看详情
第四篇css
在标签上设置style属性：background-color：#2459a2；height：48px；。。。编写CSS样式：1.在标签的属性中编写1<!DOCTYPEhtml>2<htmllang="en">3<head>4<metacharset="UTF-8">5<title>Title</title>6</head 查看详情
git从青铜到王者第四篇:git的分支与合并(代码片段)
系列文章目录文章目录系列文章目录前言一、Git分支1.Git分支简介2.Git分支创建3.Git分支切换二、Git分支的新建与合并1.新建分支2.分支的合并3.遇到冲突时的分支合并三、分支管理四、分支开发工作流1.长期分支2.主题分支五、远... 查看详情
第四篇javascript
一、正则表达式提示：此专题需要多轮复习反复的加深和理解正则表达式的两种用法：1）regexp.xxx(string);2)string.yyy(regexp);验证用户输入的手机号格式是否合法varregexp=/^1[3-8]d{9}$/;varinput="15012345678";console.log(regexp.test(input))正则表达式... 查看详情
小白入门深度学习|第四篇：配置pytorch环境
第四篇其他软件的安装方法
这篇是预留的一篇文章，主要用来记录其他软件的安装方法。占个位置。 查看详情
第四篇alexnet——网络实战
文章目录摘要1项目结构2划分训练集和测试集3计算mean和Standard3.1标准化的作用3.2归一化的作用4训练4.1导入项目使用的库4.2设置随机因子 查看详情
第四篇alexnet——网络实战
文章目录摘要1项目结构2划分训练集和测试集3计算mean和Standard3.1标准化的作用3.2归一化的作用4训练4.1导入项目使用的库4.2设置随机因子 查看详情
coreanimation文档翻译（第四篇）
CoreAnimation文档翻译（第四篇）让Layer的content动画起来核心动画的基础接口以及为拥有Layer的View做的动画扩展接口，使得为Layer制作复杂动画变得简单化。例如改变Layer的frame的size、改变Layer在屏幕上的position、应用旋转transform、或... 查看详情
css样式第四篇
?针对现在网站的图片过大问题，可以用相应的工具进行压缩，并且可对图片进行切割处理。1.如果一个页面的图片过大，可以对其切割，代码<imgsrc=”1.jpg”><imgsrc=”2.jpg”><imgsrc=”3.jpg”>,如这样排列的图片不是块... 查看详情