Android Gradle知识梳理

Android Studio已经成为现在Android 开发的主要工具，在开发过程中学习使用gradle显得格外重要，本篇博客，我们一起学习gradle打包的一些知识。

Gradle 安装

1.安装JDK，并配置JAVA_HOME环境变量。因为Gradle是用Groovy编写的，而Groovy基于JAVA。另外，Java版本要不小于1.5.
2.下载。地址是：http://www.gradle.org/downloads

选择Download，选择相应的complete版本即可

3.解压。如果你下载的是gradle-xx-all.zip的完整包，它会有以下内容：
二进制文件
用户手册（包括PDF和HTML两种版本）
DSL参考指南
API手册（包括Javadoc和Groovydoc）
样例
源代码，仅供参考使用。

4.配置环境变量。配置GRADLE_HOME到你的gradle根目录当中，然后把%GRADLE_HOME%/bin（linux或mac的是$GRADLE_HOME/bin）加到PATH的环境变量。

配置完成之后，运行gradle -v，检查一下是否安装无误。如果安装正确，它会打印出Gradle的版本信息，包括它的构建信息，Groovy, Ant, Ivy, 当前JVM和当前系统的版本信息。

另外，可以通过GRADLE_OPTS或JAVA_OPTS来配置Gradle运行时的JVM参数。不过，JAVA_OPTS设置的参数也会影响到其他的JAVA应用程序。

Gradle构建基础

Projects和tasks
先介绍两个概念，projects和tasks，它们是Gradle中的两个重要概念。
任何一个Gradle构建，都是由一个或多个projects组成的。Project就是你想要用Gradle做什么，比如构建一个jar包，构建一个web应用。Project也不单指构建操作，部署你的应用或搭建一个环境，也可以是一个project。
一个project由多个task组成。每个task代表了构建过程当中的一个原子性操作，比如编译，打包，生成javadoc，发布等等这些操作。

编写第一个构建脚本
新建一个文件build.gradle，然后添加以下代码：

task hello {  
    doLast {  
        println 'Hello, Gradle!'  
    }  
} 

这是一个非常简单的构建脚本，它定义了一个叫hello的task，task的内容是在最后打印出“Hello, Gradle!”。
输入命令gradle hello来执行它：

Gradle是领域驱动设计的构建工具，在它的实现当中，Project接口对应上面的project概念，Task接口对应上面的task概念，实际上除此之外还有一个重要的领域对象，即Action，对应的是task里面具体的某一个操作。一个project由多个task组成，一个task也是由多个action组成。
当执行gradle hello的时候，Gradle就会去调用这个hello task来执行给定操作(Action)。这个操作其实就是一个用Groovy代码写的闭包，代码中的task是Project类里的一个方法，通过调用这里的task方法创建了一个Task对象，并在对象的doLast方法中传入println ‘Hello, Gradle!’这个闭包。这个闭包就是一个Action。
Task是Gradle里定义的一个接口，表示上述概念中的task。它定义了一系列的诸如doLast, doFirst等抽象方法，具体可以看gradle api里org.gradle.api.Task的文档。

在上面执行了gradle hello后，除了输出“Hello, Gradle!”之外，我们发现像“:hello”这样的其他内容。这其实是Gradle打印出来的日志，如果不想输出这些内容，可以在gradle后面加上参数 -q。即：gradle -q hello。

快速定义任务
上面的代码，还有一种更简洁的写法，如下：

task hello << {  
    println 'Hello, Gradle!'  
}  

task hello << {
println ‘Hello, Gradle!’
}
代码即脚本
Gradle脚本是采用Groovy编写的，所以也像Groovy一样，以脚本方式来执行代码，如下面例子：

task upper << {  
    String someString = 'myName'  
    println "Original: " + someString   
    println "Upper case: " + someString.toUpperCase()  
}  

执行结果如下，它将定义的字符串转为大写：

D:\testGradle>gradle -q hello
Hello, Gradle!
D:\testGradle>gradle -q upper
Original: myName
Upper case: MYNAME

我们在写Gradle脚本的时候，可以像写Groovy代码一样。而Groovy是基于Java的，兼容Java语法
任务依赖
我们可以通过以下方式创建依赖：

task hello << {  
    print 'Hello, '  
}  
task intro(dependsOn: hello) << {  
    println "Gradle!"  
}  

定义一个任务hello，输出“Hello, ”，然后定义一个任务intro，并依赖hello，输出“Gradle!”。结果是打印出“Hello, Gradle!”，如下：

D:\testGradle>gradle -q intro
Hello, Gradle!

另外，被依赖的task不必放在前面声明，在后面也是可以的，这一点在后面将会用到。

动态任务
借助于强大的Groovy，我们还可以动态地创建任务。如下代码：
我们还可以动态地创建任务。如下代码：

4.times { counter ->  
    task "task$counter" << {  
        println "I'm task number $counter"  
    }  
}  

我们定义了4个task，分别是task0, task1, task2, task3。我们来执行task1，如下：

D:\testGradle>gradle -q task1
I'm task number 1

任务操纵
在Gradle当中，任务创建之后可以通过API进行访问，这是Gradle与Ant的不同之处。
增加依赖
还是以上面的例子，但是我们添加一行代码，如下：

4.times { counter ->  
    task "task$counter" << {  
        println "I'm task number $counter"  
    }  
}  
task1.dependsOn task0, task3  

然后还是执行 gradle -q task1

gradle -q task1
I'm task number 0
I'm task number 3
I'm task number 1

它先执行了task0和task3，因为task1依赖于这两个。

增加任务行为

task hello << {  
    println 'Hello, Gradle!'  
}  
hello.doFirst {  
    println 'I am first.'  
}  
hello.doLast {  
    println 'I am last.'  
}  
hello << {  
    println 'I am the the last'  
}  

执行后的输出：

gradle -q hello
I am first.
Hello, Gradle!
I am last.
I am the the last

短标记法
如果你对groovy有一定了解，那你也许会注意到，每个task都是一个构建脚本的属性，所以可以通过“$”这种短标记法来访问任务。如下：

task hello << {  
    println 'Hello, Gradle!'  
}  
hello.doLast {  
    println "Greetings from the $hello.name task."  
}  

执行结果：

gradle -q hello
Hello, Gradle!
Greetings from the hello task.

注意，通过这种方法访问的任务一定是要已经定义的。

增加自定义属性

task myTask {  
    ext.myProperty = "myValue"  
}  

task printTaskProperties << {  
    println myTask.myProperty  
}  

输出结果：
gradle -q printTaskProperties
myValue

定义默认任务

defaultTasks 'clean', 'run'  

task clean << {  
    println 'Default Cleaning!'  
}  

task run << {  
    println 'Default Running!'  
}  

task other << {  
    println "I'm not a default task!"  
}  

执行结果：
gradle -q
Default Cleaning!
Default Running!

DAG配置

Gradle使用DAG（Directed acyclic graph，有向非循环图）来决定任务执行的顺序。通过这一特性，我们可以实现依赖任务做不同输出。
如下代码：

task distribution << {  
    println "We build the zip with version=$version"  
}  

task release(dependsOn: 'distribution') << {  
    println 'We release now'  
}  

gradle.taskGraph.whenReady {taskGraph ->  
    if (taskGraph.hasTask(release)) {  
        version = '1.0'  
    } else {  
        version = '1.0-SNAPSHOT'  
    }  
}  

执行结果如下：
gradle -q
Default Cleaning!
Default Running!
D:\testGradle>gradle -q distribution
We build the zip with version=1.0-SNAPSHOT
D:\testGradle> gradle -q release
We build the zip with version=1.0
We release now

在上面的脚本代码中，whenReady会在release任务执行之前影响它，即使这个任务不是主要的任务（即不是通过命令行传入参数来调用）。

————–接下来是Android Gradle打包的小技巧———–

替换AndroidManifest中的占位符

把配置中的${app_label}替换为@string/app_name

android{
    defaultConfig{
        manifestPlaceholders = [app_label:"@string/app_name"]
    }
}

如果只想替换debug版本：

android{
    buildTypes {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
        }
    }
}

更多的需求是替换渠道编号：

android{
    productFlavors {
        // 把dev产品型号的apk的AndroidManifest中的channel替换dev
        "dev"{
            manifestPlaceholders = [channel:"dev"]
        }
    }
}

独立配置签名信息

对于签名相关的信息,直接写在gradle当然不好,特别是一些开源项目，可以添加到gradle.properties:

RELEASE_KEY_PASSWORD=xxxx 
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks

然后在build.gradle中引用即可：

android {
    signingConfigs {
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }
}

如果不想提交到版本库，可以添加到local.properties中，然后在build.gradle中读取。

多渠道打包

多渠道打包的关键之处在于，定义不同的product flavor, 并把AndroiManifest中的channel渠道编号替换为对应的flavor标识：

android {
    productFlavors {
        dev{
            manifestPlaceholders = [channel:"dev"]
        }
        official{
            manifestPlaceholders = [channel:"official"]
        }
        // ... ...
        wandoujia{
            manifestPlaceholders = [channel:"wandoujia"]
        }
        xiaomi{
            manifestPlaceholders = [channel:"xiaomi"]
        }
        "360"{
            manifestPlaceholders = [channel:"360"]
        }
}

注意一点，这里的flavor名如果是数字开头，必须用引号引起来。
构建一下，就能生成一系列的Build Variant了:

devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release

其中debug, release是gradle默认自带的两个build type, 下一节还会继续说明。选择一个，就能编译出对应渠道的apk了。

自定义Build Type

前面说到默认的build type有两种debug和release，区别如下：

// release版本生成的BuildConfig特性信息
public final class BuildConfig {
  public static final boolean DEBUG = false;
  public static final String BUILD_TYPE = "release";
}
// debug版本生成的BuildConfig特性信息
public final class BuildConfig {
  public static final boolean DEBUG = true;
  public static final String BUILD_TYPE = "debug";
}

现在有一种需求，增加一种build type，介于debug和release之间，就是和release版本一样，但是要保留debug状态（如果做过rom开发的话，类似于user debug版本），我们称为preview版本吧。
其实很简单：

android {
    signingConfigs {
        debug {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        preview {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }
    buildTypes {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
        }
    }
}

另外，build type还有一个好处，如果想要一次性生成所有的preview版本，执行assemblePreview即可，debug和releae版本同理。

build type中的定制参数

上面我们在不同的build type替换${app_label}为不同的字符串，这样安装到手机上就能明显的区分出不同build type的版本。
除此之外，可能还可以配置一些参数，我这里列几个我在工作中用到的：

android {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
            applicationIdSuffix ".debug"
            minifyEnabled false
            signingConfig signingConfigs.debug
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
            applicationIdSuffix ".preview"
            debuggable true // 保留debug信息
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.preview
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

这些都用的太多了，稍微解释一下：

// minifyEnabled 混淆处理
// shrinkResources 去除无用资源
// signingConfig 签名
// proguardFiles 混淆配置
// applicationIdSuffix 增加APP ID的后缀
// debuggable 是否保留调试信息
// ... ...

多工程全局配置

随着产品渠道的铺开，往往一套代码需要支持多个产品形态，这就需要抽象出主要代码到一个Library，然后基于Library扩展几个App Module。
相信每个module的build.gradle都会有这个代码：

android {
    compileSdkVersion 22
    buildToolsVersion "23.0.1"
    defaultConfig {
        minSdkVersion 10
        targetSdkVersion 22
        versionCode 34
        versionName "v2.6.1"
    }

当升级sdk、build tool、target sdk等，几个module都要更改，非常的麻烦。最重要的是，很容易忘记，最终导致app module之间的差异不统一，也不可控。
强大的gradle插件在1.1.0支持全局变量设定，一举解决了这个问题。
先在project的根目录下的build.gradle定义ext全局变量:

ext {
    compileSdkVersion = 22
    buildToolsVersion = "23.0.1"
    minSdkVersion = 10
    targetSdkVersion = 22
    versionCode = 34
    versionName = "v2.6.1"
}

然后在各module的build.gradle中引用如下：

Android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
    defaultConfig {
        applicationId "com.xxx.xxx"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode rootProject.ext.versionCode
        versionName rootProject.ext.versionName
    }
}

然后每次修改project级别的build.gradle即可实现全局统一配置。

自定义导出的APK名称

默认android studio生成的apk名称为app-debug.apk或者app-release.apk，当有多个渠道的时候，需要同时编出50个渠道包的时候，就麻烦了，不知道谁是谁了。
这个时候，就需要自定义导出的APK名称了，不同的渠道编出的APK的文件名应该是不一样的。

android {
    // rename the apk with the version name
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent,
                    "lol-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

当apk太多时，如果能把apk按debug，release，preview分一下类就更好了（事实上，对于我这样经常发版的人，一编往往就要编四五十个版本的人，debug和release版本全混在一起没法看，必须分类），简单：

android {
    // rename the apk with the version name
    // add output file sub folder by build type
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent + "/${variant.buildType.name}",
                    "lol-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

现在生成了类似于lol-dev-preview-v2.4.0.0.apk这样格式的包了，preview的包自然就放在preview的文件夹下，清晰明了。

混淆技巧

混淆能让反编译的代码可读性变的很差，而且还能显著的减少APK包的大小。

第一个技巧

相信很多朋友对混淆都觉得麻烦，甚至说，非常乱。因为添加混淆规则需要查询官方说明文档，甚至有的官方文档还没说明。当你引用了太多库后，添加混淆规则将使一场噩梦。
这里介绍一个技巧，不用查官方文档，不用逐个库考虑添加规则。
首先，除了默认的混淆配置(android-sdk/tools/proguard/proguard-android.txt), 自己的代码肯定是要自己配置的：
接下来是麻烦的第三方库，一般来说，如果是极光推的话，它的包名是cn.jpush, 添加如下代码即可：

dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }

其他的第三库也是如此，一个一个添加，太累！其实可以用第三方反编译工具（比如jadx：https://github.com/skylot/jadx ），打开apk后，一眼就能看到引用的所有第三方库的包名，把所有不想混淆或者不确定能不能混淆的，直接都添加又有何不可：

#####################################
######### 第三方库或者jar包 ###########
#####################################
-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }
-dontwarn com.squareup.**
-keep class com.squareup.** { *; }
-dontwarn com.octo.**
-keep class com.octo.** { *; }
-dontwarn de.**
-keep class de.** { *; }
-dontwarn javax.**
-keep class javax.** { *; }
-dontwarn org.**
-keep class org.** { *; }
-dontwarn u.aly.**
-keep class u.aly.** { *; }
-dontwarn uk.**
-keep class uk.** { *; }
-dontwarn com.baidu.**
-keep class com.baidu.** { *; }
-dontwarn com.facebook.**
-keep class com.facebook.** { *; }
-dontwarn com.google.**
-keep class com.google.** { *; }
## ... ...

第二个技巧

一般release版本混淆之后，像友盟这样的统计系统如果有崩溃异常，会记录如下：

java.lang.NullPointerException: java.lang.NullPointerException
    at com.xxx.TabMessageFragment$7.run(Unknown Source)

这个Unknown Source是很要命的，排除错误无法定位到具体行了，大大降低调试效率。
当然，友盟支持上传Mapping文件，可帮助定位，mapping文件的位置在：

project > module
> build > outputs > {flavor name} > {build type} > mapping.txt

如果版本一多，mapping.txt每次都要重新生成，还要上传，终归还是麻烦。
其实，在proguard-rules.pro中添加如下代码即可：

-keepattributes SourceFile,LineNumberTabl

当然apk包会大那么一点点（我这里6M的包，大个200k吧），但是再也不用mapping.txt也能定位到行了，为了这种解脱，这个代价是值的！

动态设置一些额外信息

假如想把当前的编译时间、编译的机器、最新的commit版本添加到apk，而这些信息又不好写在代码里，强大的gradle给了我创造可能的自信：

android {
    defaultConfig {
        resValue "string", "build_time", buildTime()
        resValue "string", "build_host", hostName()
        resValue "string", "build_revision", revision()
    }
}
def buildTime() {
    return new Date().format("yyyy-MM-dd HH:mm:ss")
}
def hostName() {
    return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
}
def revision() {
    def code = new ByteArrayOutputStream()
    exec {
        commandLine 'git', 'rev-parse', '--short', 'HEAD'
        standardOutput = code
    }
    return code.toString()
}

上述代码实现了动态的添加了3个字符串资源: build_time、build_host、build_revision, 然后在其他地方可像如引用字符串一样使用如下：

// 在Activity里调用
getString(R.string.build_time)  
getString(R.string.build_host)  
getString(R.string.build_revision) 

给自己留个”后门”: 点七下

为了调试方便，我们往往会在debug版本留一个显示我们想看的界面，如何进入到一个界面，我们可以仿照android开发者选项的方式，点七下才显示，我们来实现一个：

private int clickCount = 0;
private long clickTime = 0;
sevenClickView.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        if (clickTime == 0) {
            clickTime = System.currentTimeMillis();
        }
        if (System.currentTimeMillis() - clickTime > 500) {
            clickCount = 0;
        } else {
            clickCount++;
        }
        clickTime = System.currentTimeMillis();
        if (clickCount > 6) {
            // 点七下条件达到，跳到debug界面
        }
    }
});

release版本肯定是不能暴露这个界面的，也不能让人用am在命令行调起，如何防止呢，可以在release版本把这个debug界面的exported设为false。