Gradle学习目录总结

时间 2019-12-19

原文原文链接

若是是你想干的事情，在别人看起来多是很难的一件事，不过你本身很喜欢，你不会以为很苦。我开始创业那会是28岁。对我来说，我创业的目的不是为了本身当老板，我但愿有一个平台有一个环境，我能够控制一些资源，让我去创造一个新的产品和服务；
—— 周鸿祎php

Gradle是一种依赖管理工具，基于Groovy语言，面向Java应用为主，它抛弃了基于XML的各类繁琐配置，取而代之的是一种基于Groovy的领域特定（DSL）语言。css

固然，咱们如今最多都是在Android Studio的项目中，和我同样没有接触过的就当看看个人学习笔记吧。java

阅读第一个gradle

随便找到了一个Android Sdk中的一个Sample代码，看了一下它的gradle脚本。以下所示：android

apply plugin: 'com.android.application' android { compileSdkVersion 21 #build的sdk版本 buildToolsVersion "21.1.2" #build的工具版本 defaultConfig { #默认配置，versionname，versioncode等 applicationId "com.example.hello" minSdkVersion 15 targetSdkVersion 21 versionCode 1 versionName "1.0" } buildTypes { #编译方式 release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { #第三方依赖库 compile fileTree(include: ['*.jar'], dir: 'libs') compile 'com.android.support:appcompat-v7:21.0.3' }

咱们从阅读上看来是很简单的，咱们彻底没有学习过gradle也可以看到它的脚本大概的意思。那么，咱们该如何书写此类脚本能？这类的脚本又可以帮助咱们作一些什么复杂的事情？数组

因为在网上也没有找到一个比较全面的Android Gradle教程，因此，本身根据官方的入门文档：
http://tools.android.com/tech-docs/new-build-system/user-guide安全

翻译文以下：ruby

说明

简单的构建文件，最简单的纯Java项目的build.gradle以下所示：bash

apply plugin: 'java'

这里配置使用了Gradle内置的 Java 插件。该插件提供用于构建并测试 Java 应用程序所须要的东西。服务器

最简单的 Android 项目的 build.gradle 则是如下内容：闭包

buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.11.1' } } apply plugin: 'android' android { compileSdkVersion 19 buildToolsVersion "19.0.0" }

在这个 Android 构建文件中，有3个主要部分：

buildscript：配置了驱动构建的代码。
apply plugin： android插件，配置构建Android须要的东西。
android：配置了用于 android 构建的全部参数。

Tips：你应该只配置使用这个android插件。若是同时配置使用了java插件也会致使构建错误。

工程结构

基本项目开始于两个名为“source sets”的组件。即主源代码和测试代码。它们分别在：

src/main/
src/androidTest/

里面的每一个文件夹中都存在对应的源代码组件的文件夹。

对于 Java 和 Android 插件，Java 源代码和 Java 资源的位置以下：

java/
resources/

对于Android 插件，Android所特有的额外的文件和文件夹是：

AndroidManifest.xml
res/
assets/
aidl/
res/
jni/

注： src/androidTest/AndroidManifest.xml是不须要的，由于它会被自动建立。

项目配置结构

当IDE环境没有自动的生成构建的Gradle脚本，咱们能够根据 Gradle 文档，为一个Java 项目从新配置 sourceSets能够经过以下方法实现：

sourceSets { main { java { srcDir 'src/java' } resources { srcDir 'src/resources' } } }

注： srcDir实际上会将给定的文件夹添加到现有的源文件夹列表中（这在Gradle 文档中没有说起，但这是实际的行为）。

若是要替换默认的源文件夹，您就要使用传入一个路径数组的srcDirs来代替。如下是使用涉及的对象的另外一种不一样的方法：

sourceSets { main.java.srcDirs = ['src/java'] main.resources.srcDirs = ['src/resources'] }

Android 插件使用相似的语法，但由于它使用它本身的sourceSets，因此在android对象里面来实现。

这里有一个例子，使用旧的项目结构的主源码并从新映射androidTest sourceSet 到tests文件夹：

android {
    sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } androidTest.setRoot('tests') } }

构建任务

常规任务

在构建文件中配置使用一个插件，将自动建立一系列要运行的构建任务。Java 插件和 Android 插件约定的任务以下：

assemble ：组装项目的输出的任务
check ：运行全部检查的任务。
build ：这个任务将执行assemble和check。
clean ：这个任务将清理项目的输出

assemble，check和build这些任务，实际上不作任何事情。他们是锚记任务，用于让插件添加实际的任务去作这些事情。这容许您可以调用一样的任务，不管项目的类型是什么，或者是配置使用了什么插件。

例如，配置使用findbugs插件将建立一个新的任务和使check任务依赖于它，使得每当调用check任务时都会调用到它。

您能够从命令行中运行下面的命令来获取更高级别的任务：

gradle tasks

下面的命令能够获得一个完整的任务列表，而且看到任务运行之间的依赖关系：

gradle tasks --all

Java项目任务

Java 插件主要建立两个任务，它们是主要锚记任务的依赖任务：

assemble
- jar 这个任务将建立输出。
check
- test 这个任务将运行测试。

jar任务自己会直接或间接地依赖其余任务：例如，classes任务用于编译 Java 代码。

testClasses任务用于编译测试，但它不多会被调用，由于test任务依赖于它（以及classes任务）。

通常状况下，你将可能永远只调用assemble或check，而无视其余任务。

Android 任务

Android 的插件使用相同的约定配置以兼容其余插件，并添加了另外的锚记任务：

assemble ：组装项目的输出的任务
check ：运行全部检查的任务。
connectedCheck：运行须要一个已链接的设备或模拟器的检查。它们将在全部已链接的设备上并行运行。
deviceCheck：使用 API链接到远程设备运行检查。这一个是在 CI 服务器上使用的。
build ：这项任务将执行assemble 和 check
clean ：这个任务将清理项目的输出

新的锚记任务是有必要的，以便可以运行按期的检查而无需链接的设备。
注意到，build任务不依赖于deviceCheck或connectedCheck。

Android 项目具备至少两个输出： debug版本的APK 和release版本的 APK。这里的每个输出都有本身的锚记任务，以便单独构建它们：

assemble
- assembleDebug
- assembleRelease

它们两个都依赖于执行构建一个 APK所需的多个步骤的其余任务。assemble任务取则依赖于这两个任务，因此调用 assemble 将会构建出这两个 APKs。

Tips：在命令行上，Gradle 支持任务名称的驼峰命名法的简写。例如： gradle aR 至关于输入 gradle
assembleRelease 只要没有其余任务匹配 “aR”

check锚记任务有它们本身的依赖项：

check
- lint
connectedCheck
- connectedAndroidTest
- connectedUiAutomatorTest （暂未实现）
deviceCheck

这个任务依赖于当其余插件实现了测试扩展点时建立的任务。
最后，该插件为全部构建类型（debug、release、test）建立了omstal/uninstall 任务，只要他们能够被安装（须要签名）。

Android基本的构建定制（这才是重点）

Android 插件提供了大量的 DSL，以经过构建系统直接地自定义大部分事情。经过 DSL 能够配置如下清单条目：

minSdkVersion
targetSdkVersion
versionCode
versionName
applicationId
（有效的包名 —— 更多的信息请参阅ApplicationId packageName）
PackageName 用于测试应用程序的包名
Instrumentation test runner

示例：

android {
    compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { versionCode 12 versionName "2.0" minSdkVersion 16 targetSdkVersion 16 } }

在android元素的内部的defaultConfig元素是定义全部这些配置的地方。

之前版本的 Android 插件使用packageName来配置清单的“packageName”属性。从 0.11.0开始，你应该在
build.gradle 中使用 applicationId 来配置清单中的“packageName”条目。它消除了应用程序的包名（指它的
ID）和java 包名之间的所引发的混乱。

在构建文件中描述它的强大之处是它能够是动态的。
例如，能够从文件中的某处或使用一些自定义的逻辑读取版本信息：

def computeVersionName() {
    ... } android { compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { versionCode 12 versionName computeVersionName() minSdkVersion 16 targetSdkVersion 16 } }

Tips：不要使用在做用域内可能与已存在的getter函数有冲突的函数名称。例如 defaultConfig { …} 实例调用 getVersionName() 时将自动使用 defaultConfig.getVersionName() 的 getter 方法，而不是自定义的方法。

若是一个属性未经过 DSL 来设置，它将使用默认值。下表描述了对于未设置的属性的处理方式。

属性名称	DSL 对象中的默认值	默认值
versionCode	-1	若是在清单中存在，则使用清单中的值
versionName	null	若是在清单中存在，则使用清单中的值
minSdkVersion	-1	若是在清单中存在，则使用清单中的值
targetSdkVersion	-1	若是在清单中存在，则使用清单中的值
applicationId	null	若是在清单中存在，则使用清单中的值
testApplicationId	null	applicationId + “.test”
testInstrumentationRunner	null
android.test.InstrumentationTestRunner
signingConfig	null	null
proguardFile	N/A (只设置)	N/A (只设置)
proguardFiles	N/A (只设置)	N/A (只设置)

第二列的值是很重要的，若是您在构建脚本中使用自定义逻辑查询这些属性的话。例如，您能够编写：

if (android.defaultConfig.testInstrumentationRunner == null) { // assign a better default... }

若是值仍然为null，那么在构建的时候它将会被设为第三列中的实际默认值，可是因为 DSL 元素不包含此默认值，所以您没法查询它。

这是为了防止解析应用程序的清单，除非真的很须要。

构建方式

默认状况下，Android 插件自动将项目设置为生成应用程序的的debug和release版本。
这两个版本的不一样，大可能是围绕在调试一个安全的（非开发版的）设备的能力，以及 apk 怎么签名。

调试版本使用自动建立的密钥/证书签名，而且密钥/证书的用户名/密码是已知的（以防止构建过程当中须要相关的信息）的。release版本在构建的时候不会进行签名，须要在以后进行签名。

这个配置是经过一个叫BuildType的对象来完成的。默认状况下，2 个实例会被建立，分别是debug版和release版。

Android 插件容许自定义这两个实例，以及建立其余的构建类型。它经过buildTypes DSL 容器来实现：

android {
    buildTypes {
        debug { applicationIdSuffix ".debug" } jnidebug.initWith(buildTypes.debug) jnidebug { packageNameSuffix ".jnidebug" jniDebuggable true } } }

上面的代码段可实现如下操做：

配置默认的Debug Build Type：
- 设置包名为.debug，以便可以在相同的设备上安装debug和release两个版本的apk
建立一个叫jnidebug的新的BuildType对象，并将其配置为debug生成类型的一个副本。
经过启用 JNI 组件的debug构建，并添加不一样的包后缀，继续配置jnidebug。

建立新的 Build Types 就是简单地在buildTypes下添加一个新的元素，而后调用 initWith()或者是使用一个闭包来配置。

如下是可能用到的属性和它们的默认值：

属性名称	debug的默认值	release/其余的默认值
debuggable	true	false
jniDebuggable	false	false
renderscriptDebuggable	false	false
renderscriptOptimLevel	3	3
applicationIdSuffix	null	null
versionNameSuffix	null	null
signingConfig	android.signingConfigs.debug	null
zipAlignEnabled	false	true
minifyEnabled	false	false
proguardFile	N/A (只设置)	N/A (只设置)
proguardFiles	N/A (只设置)	N/A (只设置)

除了这些属性，Build Types还会影响到构建的代码和资源。
对每一个Build Type都会建立一个自动匹配的sourceSet，默认位置为

src/<buildtypename>/

这意味着Build Type的名字不能为main或者是androidTest （这是插件所强制的），而且它们之间必须是惟一的。

与任何其余source set同样，生成类型的source set的位置也是能够从新设置的：

android {
    sourceSets.jnidebug.setRoot('foo/jnidebug') }

此外，对于每一个Build Type，会建立一个新的assemble任务。

已经提到过的assembleDebug和assembleRelease这两个任务，这里也会讲一下它们是怎么来的。当debug和releaseBuild Types被预建立的时候，他们的任务也会被自动建立。而后，

上面的build.gradle片断也会生成一个assembleJnidebug任务，而且assemble将会依赖于它，就像它依赖于assembleDebug和assembleRelease任务同样。

Tips：请记住您能够输入gradle aJ来运行assembleJnidebug任务。

可能会用到的状况：

release模式下不须要，但debug模式下须要的权限
自定义的debug实现
为debug模式使用不一样的资源（例如某个资源的值与签名证书相绑定时）。

BuildType的代码和资源经过如下方式被使用：

manifest将被合并到应用程序的manifest中
代码只是做为另外一个源文件夹来起做用
资源将覆盖main里面的资源，并替换已经存在的值。

签名配置

对应用程序进行签名，要求以下：

一个 keystore
一个 keystore 的密码
一个 key 的别名
一个 key 的密码

存储类型

签名文件的位置，key的名称，以及这两个密码和存储类型，一块儿构成了一个签名配置（ SigningConfig类型）

默认状况下，有一个debug的配置，配置使用了一个debug keystore。这个keystore使用了一个已知的key和一个已知的密码。

这个debug keystore 位于$HOME/.android/debug.keystore，而且会在不存在时被建立。debug Build Type被设置为自动使用此debug

签名配置

你也能够建立其余配置，或者自定义某个默认的内置配置。经过signingConfigs DSL 容器来实现：

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore") } myConfig { storeFile file("other.keystore") storePassword "android" keyAlias "androiddebugkey" keyPassword "android" } } buildTypes { foo { debuggable true jniDebuggable true signingConfig signingConfigs.myConfig } } }

上面的代码段把debug keystore的位置修改成在项目的根位置下。这会自动影响到任何设置为使用它的Build Types，在这里，影响到的是debug Build Type。

代码的代码还建立了一个新的Signing Config和使用新配置的新的Build Type 。

Tips：只有位于默认位置下的debug keystores才会被自动建立。若是debug
keystore的位置被更改了，它将不会在须要时自动建立。建立一个使用一个不一样的名称SigningConfig，但使用了默认的debug

Tips： keystore的路径一般使用项目根目录的相对路径，但也能够是使用绝对路径，尽管这不推荐（除了自动建立的debug keystore）。——–

运行ProGuard

ProGuard 是经过 Gradle plugin for ProGuard version 4.10来进行支持的。ProGuard 插件会被自动配置使用，而且若是Build Type经过minifyEnabled属性配置为运行ProGuard，对应的任务将被自动建立。

android { buildTypes { release { minifyEnabled true proguardFile getDefaultProguardFile('proguard-android.txt') } } productFlavors { flavor1 { } flavor2 { proguardFile 'some-other-rules.txt' } } }

变种使用他们的构建类型中所声明的规则文件，product flavors（定制版本）则使用flavor中声明的规则文件。

这里有 2 个默认的规则文件

proguard-android.txt
proguard-android-optimize.txt

它们位于 SDK 中。使用getDefaultProguardFile()将返回的文件的完整路径。它们除了是否启用优化以外，其它都是相同的。

依赖、注入库、多项目构建设置

Gradle 项目能够对其余组件具备依赖关系。这些组件能够是外部的二进制包，或其余的 Gradle 项目。

二进制包的依赖

本地包
要配置一个外部库 jar 包的依赖，您须要在compile配置中添加一个依赖关系。

dependencies {
    compile files('libs/foo.jar') } android { ... }

Tips：dependencies DSL 元素是标准的 Gradle API 的一部分，不属于android 元素内。

compile配置用于编译主应用程序。里面的全部内容都会被添加到编译类路径，而且打包到最终生成的 apk 当中。下面是添加依赖时其余可能用到的配置：

compile: 主应用程序
androidTestCompile: 测试的应用程序
debugCompile: debug Build Type
releaseCompile: release Build Type.

由于不可能构建一个没有任何关联的Build Type的 APK，apk 老是配置两个（或以上）的配置：compile和Compile。
建立一个新的Build Type会基于它的名字自动建立一个新的配置。

这可能会有用，好比debug版本须要使用一个自定义库（例如报告崩溃的信息），而release版本则不须要，或者是他们依赖于同一个库的不一样版本的状况下。

远程工程

Gradle 支持从 Maven 和 Ivy 仓库中拉取文件。

首先，这个仓库必须添加到列表当中，而后必须用Maven 或 Ivy 声明文件的方式声明这个

repositories {
    mavenCentral()
}


dependencies {
    compile 'com.google.guava:guava:11.0.2' } android { ... }

mavenCentral()是指定maven中央仓库的URL的快捷方法。Gradle支持远程和本地仓库。

Tips：Gradle 将遵循全部依赖关系的传递性。这意味着，若是一个依赖有它本身的依赖关系，这些依赖也会被拉取。

有关设置依赖关系的更多信息，请参阅 Gradle 用户指南（这里），和DSL文档（这里）。

多工程设置

Gradle 项目也能够经过使用多项目设置依赖于其余的 Gradle 项目。

一个多项目设置一般是经过让全部的项目做为给定根项目的子文件夹来实现。

例如，给定如下项目结构：

MyProject/
 + app/
 + libraries/
    + lib1/
    + lib2/

咱们能够识别出3个项目。Gradle 将经过如下名称引用它们：

:app
:libraries:lib1 :libraries:lib2

每个项目都有其本身的build.gradle文件，定义本身如何构建。
此外，在根路径下还将有一个叫settings.gradle的文件用于声明全部的项目。
这些文件的结构以下：

MyProject/
 | settings.gradle + app/ | build.gradle + libraries/ + lib1/ | build.gradle + lib2/ | build.gradle

settings.gradle的内容很简单：

include ':app', ':libraries:lib1', ':libraries:lib2'

它定义了哪一个文件夹其实是一个 Gradle 项目。

该:app项目可能依赖于libraries，这是经过声明以下的依赖关系来配置的：

dependencies {
    compile project(':libraries:lib1') }

库项目

在上面的多项目的设置中，:libraries:lib1和:libraries:lib2能够是Java项目，而:app Android项目将会使用到它们的jar包输出。

可是，若是你想共享访问了 Android API或使用了 Android-style的资源的代码，这些库项目就不能是普通的Java项目，而应该是 Android Library 项目。
建立库项目
Library项目与普通的 Android 项目很是类似，只有一些不一样。

因为构建库项目与构建应用程序有些不一样不一样，因此使用的是不一样的插件。这两个插件内部共享了大部分的相同的代码，而且它们都由一样的com.android.tools.build.gradle jar 包提供。

buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.5.6' } } apply plugin: 'android-library' android { compileSdkVersion 15 }

上面的例子中建立了一个使用API 15编译的库项目。SourceSets和依赖关系与它们在应用程序项目中的处理方式同样，而且支持一样方式的自定义。

普通项目和Library 项目之间的区别

一个 Library 项目主要输出的是一个.aar包（它表明Android的归档文件）。它组合了编译代码（如一个jar文件或原生的.so文件）和资源（manifest，res，assets）。
一个库项目还能够生成测试apk，独立于应用程序测试这个库。

库项目用着一样的锚任务（assembleDebug， assembleRelease），因此构建这样一个项目的命令也没有任何区别。

对于其余的内容，库项目和应用程序项目的行为是同样的。。他们都有构建类型（build types）和产品定制（product flavors），而且均可以生成多个版本的aar。
须要注意的是，Build Type的大部分配置都不适用库项目。可是，您能够根据一个库项目是否被其余项目使用仍是被测试，使用自定义 sourceSet 来更改库项目的内容。

引用一个库项目

引用一个库库和引用其余任何项目的方法是同样的：

dependencies {
    compile project(':libraries:lib1') compile project(':libraries:lib2') }

Tips：若是您有多个库，那么排序将很是重要。这相似于旧的生成系统中， project.properties 文件的依赖项的顺序的重要性。

库项目发布

默认状况下，一个库项目只发布它的release 变种程序。这变种程序将被全部引用该库的项目使用，不管那些项目构建的是哪一种variant。这是因为 Gradle 限制而有的一个临时限制，咱们正在努力消除这个问题。

您能够控制要发布哪个以下所示：

android {
    defaultPublishConfig "debug" }

Tips，这个发布的配置名称引用的是完整的变种程序
名称。release和debug，只在没有定义flavor时适用。若是你想在使用flavors时更改默认的发布

你能够这样写：

android {
    defaultPublishConfig "flavor1Debug" }

发布一个库项目的全部变种程序也是能够作到的。咱们正计划在正常的项目对项目（project-to-project）的依赖（如上面的例子）时也能够这样作，但如今由于 Gradle 的限制（咱们也在努力修复这些问题)，还没法作到。

默认状况下没有启用发布全部变种程序。要启用它们

android {
    publishNonDefault true }

变种程序意味着发布多个aar文件，而不是发布一个包含多个变种程序的aar文件，能意识到这一点是很是重要的。每个 aar 包都是包含一个单一的变种程序。

发布一个变种程序，意识着让这个可用的 aar 做为 Gradle 项目的输出文件。这个文件将会在发布到一个maven仓库中，或者另外一个项目建立对这个项目依赖时用到。

Gradle 有一个默认文件的概念。它就是在编写下面的代码时用到的：

compile project(':libraries:lib2')

若要建立对一个项目的另外一个已发布的文件的依赖，您须要指定使用哪个：

dependencies {
    flavor1Compile project(path: ':lib1', configuration: 'flavor1Release') flavor2Compile project(path: ':lib1', configuration: 'flavor2Release') }