Gradle日常开发技巧总结

一、基础概念篇

1、Gradle：是一个工具，同时它也是一个编程框架。使用这个工具可以完成app的编译打包等工作。

通过安装Gradle插件让系统能支持运行Gradle。安装AS后就已经帮我安装了Gradle插件。但Gradle插件是独立于Android Studio运行的。

2、Gradle version：配置文件路径==>youProject/gradle/wrapper/gradle-wrapper.properties

#Mon Dec 28 10:00:20 PST 2015
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-3.3-all.zip

3、android gradle 插件的版本：配置文件路径==>youProject/build.gradle(工程级别的build.gradle文件)

// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.3'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

• 注：gradle插件的版本号和gradle版本号是对应的，较新的插件版本需要要求较新版的gradle，所以提示你更新gradle；

二、build.gradle配置文件解析：(module级别的build.gradle文件)

apply plugin: 'com.android.application'
apply plugin: 'android-apt'

android {
    compileSdkVersion 23
    buildToolsVersion '25.0.0'

    defaultConfig {
        applicationId "com.mobilesafe"
        minSdkVersion 19
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

        //加载so库目录
        sourceSets {
            main {
                // Tell Android Gradle that no jni code need to compile, so we can avoid Ndk compile task,
                // then we will to compile use ndk-build in command-line.
                jni.srcDirs = [] // 不使用 gradle 进行 ndk 编译
                jniLibs.srcDir "src/main/libs" // 指定加载so库目录
            }
        } 
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    testOptions {
        unitTests.returnDefaultValues = true
    }
}
configurations.all {
    resolutionStrategy {
        force 'com.android.support:support-annotations:23.1.1'
    }
}
dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'junit:junit:4.12'
    testCompile 'junit:junit:4.12'
    testCompile 'org.mockito:mockito-core:1.9.5'
    compile 'com.android.support:appcompat-v7:23.4.0'
    compile 'com.jakewharton:butterknife:8.1.0'
    apt 'com.jakewharton:butterknife-compiler:8.1.0'
    compile files('libs/afinal_0.5_bin.jar')
    androidTestCompile 'com.android.support.test:runner:0.4'
}

1、apply plugin：用来指定用的是哪个插件，开发中常见的值有

'com.android.application'：Android APP插件（打包得到的是.apk文件）
'com.android.library':Android库插件（打包得到的是.aar文件）
'java':普通的java插件（打包得到的是.jar文件）

2、android{}：用来指定Android打包插件的相关属性，其包含如下节点

compileSdkVersion(apiLevel)：设置编译时使用的Android SDK版本(是告诉gradle 用哪个SDK版本来编译，和运行时要求的版本号没有关系；使用任何新添加的 API 就需要使用对应 Level 的 Android SDK。)
buildToolsVersion(buildToolsVersionName)：设置编译时使用的构建工具的版本(android构建工具的版本，其中包括了打包工具aapt、dx等等。这个工具的目录位于..your_sdk_path/build-tools/XX.XX.XX，通过SDK Manager 更新；)
defaultConfig：设置一些默认属性，其可用属性是buildTypes和productFlavors之和。（productFlavors默认文件里没有，会在后面介绍）

3、buildTypes：配置构建类型，可打出不同类型的包，常见的有debug和release两种，当然你还可以再增加N种
4、productFlavors：配置不同风格的APP，在buildTypes的基础上还可以让每一个类型的APP拥有不同的风格，所以最终可以打出的APK的数量就是buildTypes乘以productFlavors。构建的变量名称是productFlavors+buildTypes。
5、dependencies：配置依赖,这项可定是从eclipse换到studio后感觉最方便的一处了。各种外部依赖直接一行代码搞定，不用手动下依赖包了。
其中compile fileTree(dir: ‘libs’, include: [‘*.jar’])的意思是依赖libs目录下全部的jar文件。

三、高级技巧

1、manifest动态配置
很多第三方SDK需要在AndroidManifest.xml中配置你的一些key信息，以友盟推送为例：

<meta-data 
    android:value="YOUR_APP_KEY" 
    android:name="UMENG_APPKEY"/>

但是你不同测试包和正式包的key是不同的，那么就可以这么修改：

<meta-data
    android:name="UMENG_APPKEY"
    android:value="${UMENG_APPKEY}" />

然后在productFlavors中的各个版本中加上不同的信息，这样你打出的不同包采用的appkey也会不一样。

manifestPlaceholders = [UMENG_CHANNEL: "0", UMENG_APPKEY : "123456789"]

不仅这些自定义元数据可以动态配置，android:icon，android:label这些标签也可以修改，这样打出的不同包就有不同的图标了，方便做区分。
2、Moudle动态依赖
在组件化app里面，我们可能在测试包和正式包需要依赖不同组件。比如测试环境需要调试模块，但正式环境不需要。假如productFlavors如下，调试模块名字为module-test。

productFlavors {
    ceshi{
    }
    publish{
    }
}

那么在dependencies里面就可以这么依赖test模块：

ceshiCompile project(':module-test')

同样buildTypes也是适用的，两者可以一起或单独使用：

debugCompile project(':module-test') 
ceshidebugCompile project(':module-test')

3、代码中读取变量
上面的这些功能都是gradle单独配置的，但我们往往针对不同的构建包有不同的需要在代码中体现的需求：日志打印，Toast等等。
虽然BuildConfig.DEBUG字段就可以判断，但我们可以用buildConfigField向代码中传递自定义的值，比如不同构建包需要不同Host开头的api地址，不同的https证书路径等，用法为：

buildConfigField 'type', 'name', '"vaule"'

比如：

defaultConfig {
    buildConfigField 'String', 'author', '"renny"'
}

上面的是加在defaultConfig 中的，而加在buildTypes或productFlavors中就会在不同构建版本出现不同的值。如果再配置上不同的applicationId，那么就可以在同一个手机上同时安装不同构建版本的应用。

productFlavors {
    ceshi{
        applicationId "com.renny.test"
        buildConfigField "String", "API_TEST", "http://test.renny.com/android" 
    }
    publish{
        applicationId "com.example.publish"
        buildConfigField "String", "API_PUBLISH", "http://publish.renny.com/android"
    }
}

经过上面的介绍，你可能会发现buildTypes和productFlavors定义很相似，不过他们的差别在于改变 buildType 不会改变应用程序的代码，它们只是处理的东西不同，你可以通过 buildType 来获取更多的技术细节（例如：build optimization,log level 等等），但是app的内容不会改变，相反的，使用productFlavor 配置可以改变app的内容(ps:内容可以设想成 package 理解，buildType 没法改 applicationId)。

四、Gradle task

Gradle task适合用来完成一些既繁琐又容易出错的重复性手工作，比如批量修改，复制，重命名文件。
比如applicationVariants.all这个task可以针对每个构建版本设置各种属性，比如修改每个构建版本生成的apk名字：

applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent,
                    ("app-${variant.buildType.name}"+"-" + new Date().format('yyyyMMdd') + ".apk").toLowerCase())
        }
    }

gradle会默认匹配生成每种productFlavors*buildTypes的构建版本，如果你想跳过其中的几种就可以这么做：

variantFilter { variant ->
    if (variant.buildType.name.equals('release')) {
        variant.setIgnore(!variant.getFlavors().get(1).name.equals('ceshi'));
    }
    if (variant.buildType.name.equals('debug')) {
        variant.setIgnore(variant.getFlavors().get(1).name.equals('ceshi'));
    }
}