Gradle使用技巧总结

转载自：

https://www.jianshu.com/p/5be222e98efc?from=jiantop.com

记录使用Android Studio以及Gradle的心路历程。系列文章将持续更新中。。。

加速篇

第一次加载项目缓慢

对于初用Android Studio的朋友来说，项目构建是一个很缓慢的过程，因为中间会下载好多好多东西。这里我仅总结下如何提升编译过程中的下载组件部分，其他什么daemon或是configureondemand我在使用时候发现几乎没有什么效果。
我以lottie-android为例，先看看它的目录结构

lottie-android

(1) 确定根目录下的build.gradle中Android Gradle Plugin版本是否与本地插件版本一直，若不一直修改为本地插件版本

Android Gradle Plugin插件版本

这里是2.3.0-beta3，我本地是2.2.3，直接修改成我本地的版本号即可
(2) 确定gradle/wrapper/gradle-wrapper.properties文件中gradle的版本在C:\Users\用户名\.gradle\wrapper\dists是否已经离线存在

gradle的版本

这里是3.3，我本地是2.14.1，直接修改成我本地的版本号即可
(3) 分别查看各个module中的build.gradle里面compileSdkVersion、buildToolsVersion、com.android.support等Android SDK的相应版本是否已经存在。
(4) 如果存在其他第三方库，若能提前下载完成最好。已经下载完成的库存放在C:\Users\用户名\.gradle\caches\modules-2\files-2.1里面

第三方库存放路径

以fresco为例，如果你之前在其他电脑上找到相应完整的目录，请拷贝到其中，以节省下载所需时间
(5) 明确版本号写法的差别。先看下这几种写法，以gson为例

dependencies {
    compile 'com.google.code.gson:gson:2.2.1'
    compile 'com.google.code.gson:gson:2.2.＋'
    compile 'com.google.code.gson:gson:2.＋'
    compile 'com.google.code.gson:gson:＋'
}

大家大概心里有数了吧，版本号模糊，就意味着每次都要去对比同步得到最新版本，时间就花费在这个上面了，所以我们的版本号一定要写精确，这样才能节省这些时间

基础配置篇

设置全局编译器的版本

在使用retrolambda的时候有过对java编译器的配置
如果仅需某一个module单独支持，只要在相应module的build.gradle下进行配置即可

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

如果你希望全局配置，则需要配置根目录下的build.gradle，在其allprojects中进行配置即可

allprojects {
    repositories {
        jcenter()
    }
    tasks.withType(JavaCompile) {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

注意设置java1.8版本需要开启jack编译，否则会抛出Error:Jack is required to support java 8 language features

defaultConfig {
    ...
    jackOptions {
        enabled true
    }
}

签名文件的存放与配置

在你的工程里，是不是这样对签名进行如下配置？

   signingConfigs {
         storeFile file("android.keystore")
         storePassword "abcd1234"
         keyAlias "android.keystore"
         keyPassword "abcd1234"
    }

这种看上去很直观，但是不好的地方就是安全性不够格。我们可以将这些高危参数放到专门的配置文件中，并且在提交代码的时候将其从版本管理中忽略。
我们将配置信息写在gradle.properties中

# keystore配置信息
storeFile_=android.keystore
storePassword_=abcd1234
keyAlias_=android.keystore
keyPassword_=abcd1234

必要信息写完之后，即可修改build.gradle中的signingConfigs，直接引用gradle.properties中的配置信息

storeFile file(storeFile_)
storePassword storePassword_
keyAlias keyAlias_
keyPassword keyPassword_

其实你可以在任何目录放置这个签名文件。如果签名信息没有放到gradle.properties或者local.properties里，那就需要自己通过代码来读取配置信息，从而获取相应的数值。这里示例是keystore.txt文件，目录与gradle.properties同级

keystore.txt

内容就不加展示了，与之前gradle.properties里面配置的一样，来看看如何加载

// 加载签名配置文件
Properties props = new Properties()
props.load(new FileInputStream(file("../gradle.properties")))
android {
    signingConfigs {
        release {
            storeFile file(props['storeFile_'])
            storePassword props['storePassword_']
            keyAlias props['keyAlias_']
            keyPassword props['keyPassword_']
        }
    }
}

占位符的使用

占位符常用在androidManifest.xml中，随后可在相应module的build.gradle中将其进行赋值。这个大多用在多渠道打包设置渠道名称上
先看下manifest文件，以友盟多渠道举例说明，这里的占位符就是UMENG_CHANNEL

<application
        .............
        <meta-data android:value="${UMENG_CHANNEL}" android:name="UMENG_CHANNEL"/>
        .............
</application>

我在defaultConfig下配置manifestPlaceholders，这里将UMENG_CHANNEL的值设置为“测试渠道”

manifestPlaceholders = [UMENG_CHANNEL : "测试渠道"]

最后使用代码验证一下

try {
    ApplicationInfo info=getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
    Log.d("MainActivity", info.metaData.getString("UMENG_CHANNEL"));
} catch (PackageManager.NameNotFoundException e) {
    e.printStackTrace();
}

正常打印

最终结果

同样的配置也可以在productFlavors上，这个就是多渠道打包中统计渠道来源的常规方法

    productFlavors {
        version1 {
            manifestPlaceholders = [UMENG_CHANNEL : "version1"]
        }
        version2 {
            manifestPlaceholders = [UMENG_CHANNEL : "version2"]
        }
    }

设置第三方远程仓库

如果我们的项目不在center或者MavenCenter的话，我们就需要单独配置maven信息了，因为我目前没有尝试搭建过maven仓库，所以在github截图来展示。关于本地Maven的操作，请参考发布Android studio项目到本地Maven仓库

maven

如果仓库在本地的话，相应url换成本地地址即可。
我一般使用的是jitpack这个远程仓库，他可以直接与github进行关联，从而生成相应的版本信息。关于jitpack的使用请参考优雅的发布Android开源库(论JitPack的优越性)

allprojects {
    repositories {
        jcenter()
        maven { url 'https://jitpack.io' }
    }
}

构建参数篇

多编译环境设置

这个就涉及到buildTypes了。在默认情况下，buildTypes可以让gradle插件自动构建一个release版本app以及一个debug版本app。这两个版本区别主要在app配置以及签名上。debug包使用默认签名信息，这个签名文件在/.android/debug.keystore，而release包需要你稍后自行配置。如果你需要创建其他的build type，你可以在buildTypes这个DSL下进行配置。
这里我给出一个简单的buildTypes配置范例

   signingConfigs {
        release {
            try {
                storeFile file("android.keystore")
                storePassword "abcd1234"
                keyAlias "android.keystore"
                keyPassword "abcd1234"
            } catch (ex) {
                throw new InvalidUserDataException(ex.toString())
            }
        }
    }
    buildTypes {
        debug {
            applicationIdSuffix '.debug'
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            signingConfig signingConfigs.release
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            shrinkResources false
            zipAlignEnabled true
        }
        // 如果我们想要新增加一个buildType，又想要新的buildType继承之前配置好的参数，init.with()就很适合你了
        hiapk.initWith(buildTypes.debug)
        hiapk {
            applicationIdSuffix '.hi'
            versionNameSuffix '.hi'
        }
    }

如此配置之后，Build Variants模块如图所示，可以得到3个不同打包配置的apk文件

variants

同时右上角那边的gradle脚本信息中也得到3个不同的编译脚本

gradle projects

buildTypes在debug包里，applicationId后缀为.debug；release包中的signingConfig文件为signingConfigs下的release；最后还有一个自己添加的buildType--hiapk，他的配置复制于debug，同时修改了applicationId后缀与versionName后缀
我们可以使用gradle build命令进行全部打包，也同样可以使用gradle assembleHiapk这种单一打包方式进行打包。打包完成之后我们反编译一下来看看三个apk的manifest信息

hiapk

release

debug

可以很清楚的看出来其中的不同
这里还有其他的DSL简单介绍一下
signingConfigs:秘钥配置信息。
shrinkResources:是否清理无用资源文件，注意如果选择true，那么minifyEnabled也得为true才行，即开启混淆
zipAlignEnabled:是否开启zipAlign压缩

编译项目时设置可引用参数

在刚才的buildTypes中有一个重要的DSL——buildConfigField，在打包编译项目时可以直接设置一些作用于项目的参数，从而在项目中使用这些参数进行逻辑层处理。buildConfigField支持Java中基本数据类型，如果是字符串，记得转义后加双引号
这里我们定义一个字符串，名称叫SERVER_HOST

buildConfigField "String", "SERVER_HOST", "\"http://200.200.200.50/\""

设置完之后编译项目，在BuildConfig.java中可以查到之前配置的相关信息

BuildConfig.java

使用时候这样

Log.d("MainActivity", BuildConfig.SERVER_HOST);

查看控制台输出

buildconfigs

玩转依赖篇

说到依赖，一般情况下我们只需要将compile远程仓库地址拷贝一下就行了，其实依赖的学问很大，远远不是compile一下而已。

依赖方式

依赖类型

Compile: 默认配置，该依赖会参与编译并且打包到所有的build type以及flavors的apk中
Provided: 对所有的build type以及flavors来说只在编译时使用，只参与编译并不打包到最终apk
APK: 只会打包到apk文件中而不参与编译，所以不能在代码中直接调用jar中的类或方法，否则在编译时会报错
另外三种compile只跟测试有关
Test compile: 仅仅是针对单元测试代码编译以及最终打包测试apk时有效，而对正常的debug或者release apk包不起作用。
Debug compile: 仅仅针对debug模式的编译和最终的debug打包时有效。
Release compile: 仅仅针对release模式的编译和最终的release打包时有效。

依赖远程文件

这是最基本的用法，在上文也提及过了

compile 'io.reactivex.rxjava2:rxandroid:2.0.1'

依赖本地文件

当前模块下libs文件夹下的全部jar文件

compile fileTree(include: ['*.jar'], dir: 'libs')

指定路径下的全部jar文件

compile fileTree(dir: '../librarymodule/libs', include: '*.jar')

加载aar文件

repositories {
    flatDir {
        dirs 'libs'
    }
}

这意味着系统将在libs目录下搜索依赖。同样的如果你愿意的话可以加入多个目录。这里系统直接加载libs文件夹下的aar文件

compile(name: 'aar的名字（不用加后缀）', ext: 'aar')

依赖本地库工程

compile project(':librarymodule')

冲突的解决方法

先来看看几种不同的写法对库的加载有何区别

// 下载包含该库在内的其他所依赖的所有库
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'

写法1

// 只下载该库，其他所依赖的所有库不下载
compile 'io.reactivex.rxjava2:rxandroid:2.0.1@aar'

写法2

// 在使用@aar的前提下还能下载其他依赖库，则需要添加transitive=true的条件
compile ("io.reactivex.rxjava2:rxandroid::2.0.1@aar") {
    transitive=true
}

写法3

// 去除某一个依赖库
compile ("io.reactivex.rxjava2:rxandroid:$rootProject.ext.rxandroid") {
    transitive=true
    exclude group: 'io.reactivex.rxjava2', module: 'rxjava'
}

写法4

这时候，我又加了一个rxbinding库，这时候依赖树是这样的结构

依赖树结构

如果我想将项目中的所有rxjava2引用都去除，可以用configurations实现

configurations {
    all*.exclude group: 'io.reactivex.rxjava2', module: 'rxjava'
}

或者这样

configurations {
    compile.exclude module: 'rxjava'
}

如果在configuration中定义一个exclude，那么所有单独设置的transitive dependency都会被去除。你可以只指定group的名字, 或只指定module的名字，或二者都指定

configurations

明白如上写法造成的区别之后，你应该就知道如何解决包冲突了吧
这里对gradle dependencies中的->、 (*)进行解释
固定版本: 唯一的依赖
固定版本(*):还存在该库其他版本的依赖或者间接依赖，并且默认选择(*)所标注的版本。这里rxjava版本就是使用rxbinding里的2.0.2
版本1->版本2(*):还存在该库其他版本的依赖或者间接依赖，并且并且选择版本2。这里rxandroid版本就是使用2.0.1
configurations DSL还可以通过Force强制约束某个库的版本，比如我这里将appcompat-v7包限定为25.1.0

configurations.all {
    resolutionStrategy {
        force "com.android.support:appcompat-v7:25.1.0"
    }
}

force

按构建目标定制依赖库

如果你想给productFlavors中的version2添加相应的依赖，只需要在它的名称后面加上Compile这样配置即可

version2Compile 'com.github.AlphaBoom:ClassifyView:0.5.2'

外部配置依赖版本

当我们直接建立完项目之后，android的相关配置就已经自动完成了，像这样

默认gradle配置

其实这样也算相对清爽吧，但是一旦引用库数量变多，这样或许就不够直观了。这种情况下，我们最好有一个单独的文件去统计这些配置。
我们新建一个config.gradle作为配置文件

config.gradle

具体配置如下

ext {
    androidGradleVersion = '2.3.1'
    AndroidSupportVersion = '25.3.1'
    AndroidConstraintLayoutVerson = '1.0.2'
    compileSdkVersion = 25
    buildToolsVersion = '25.0.2'

    defaultConfig = [
            applicationId : "com.renyu.gradledemo",
            minSdkVersion : 15,
            targetSdkVersion : 25,
            versionCode : 1,
            versionName : "1.0"
    ]
}

其中defaultConfig是一个map键值对，有别于上方的公共配置，这样看起来更清晰简洁
这里我们需要使用apply from来引用config.gradle。同理当你的gradle脚本太大的时候，你可以按照具体任务类型将一个大gradle脚本拆分成几个子脚本，然后分别apply from引入到主脚本中。

// 这里的apply是为了让子模块使用
apply from: "config.gradle"

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // root下build.gradle使用
        apply from: "config.gradle"
        classpath "com.android.tools.build:gradle:$androidGradleVersion"

        // 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
}

再看看app模块下的build.gradle的配置

apply plugin: 'com.android.application'

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
    defaultConfig {
        applicationId rootProject.ext.defaultConfig.applicationId
        minSdkVersion rootProject.ext.defaultConfig.minSdkVersion
        targetSdkVersion rootProject.ext.defaultConfig.targetSdkVersion
        versionCode rootProject.ext.defaultConfig.versionCode
        versionName rootProject.ext.defaultConfig.versionName
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    compile "com.android.support:appcompat-v7:$rootProject.ext.AndroidSupportVersion"
    compile "com.android.support.constraint:constraint-layout:$rootProject.ext.AndroidConstraintLayoutVerson"
    testCompile 'junit:junit:4.12'
}

注意这里单引号与双引号的区别，对于字符串你既可以使用单引号或者双引号，但是字符串可以插入表达式

对layout进行模块化分包

一般情况下我们app的布局文件会随着项目的开发而发生爆炸式的增长

一般项目layout下文件列表

这种组织结构会让人眼花缭乱不知所措，时间久了就会忘记某个功能用的都是哪些布局文件了。今儿就来向大家介绍如何对layout进行模块化分包。
首先来看看效果

对layout进行模块化分包

怎么样，main模块与main2模块他们的布局是相互独立保存的，没有堆叠在一起。那么这个是怎么做到的呢？之前大家从eclipse直接转项目到Android Studio上的时候，不知道有没有注意到在app模块下的build.gradle有一个DSL叫sourceSets，通过修改sourceSets中的属性，可以指定哪些源文件（或文件夹下的源文件）要被编译，哪些源文件要被排除。Gradle就是通过它实现项目的布局定义。Android Studio插件默认实现了两个sourceSet：main和test。每个sourceSet都提供了一系列的属性，通过修改这些属性，可以定义该sourceSet所包含的源文件，比如java.srcDirs，res.srcDirs

sourceSets {
   main {
      java
      res
   }
   test {
      java
      res
   }
}

了解完原理之后那就看看怎么搞吧

1. 按照自己的项目需求建立layout目录，例如本文就是/alllayouts/main/layout与/alllayouts/main2/layout
2. 在module对应的build.gradle下添加sourceSets配置

sourceSets {
        main {
            res.srcDirs = [
                    'src/main/res/alllayouts/main',
                    'src/main/res/alllayouts/main2',
                    'src/main/res'
            ]
        }
    }

注意：最后一行要添加

1. Sync Now

多渠道多版本打包调试

之前在使用buildTypes的时候，我们提到过使用buildConfigField完成相应的参数初始化，这里还有一个更高级的功能，就是使用productFlavors来修改每个版本的不同部分，或者通过判断当前所使用的app是哪个版本，执行对应版本的代码。
还是先简单看下结构

productFlavors结构

然后开始build.gradle的相关配置

productFlavors {
    version1 {
    }
    version2 {
    }
}
sourceSets {
        main {
            java.srcDirs = ['src/main/java']
        }
        version1.java.srcDirs = ['src/version1/java']
        version2.java.srcDirs = ['src/version2/java']
    }

VersionInfo同时在version1与version2包里进行定义，区别仅仅在变量的值上。在sourceSets对差异部分进行配置，注意一下路径。

public class VersionInfo {
    String v="2";
}

public class VersionInfo {
    String v="1";
}

最后我们进行编译打包

编译完成后的结果

反编译查看两个包中的文件

version1

version2

这样即完成加载不同的类对象

这里还有一个补充，如果你想修改不同渠道包的包名等信息，你可以直接在productFlavors下进行配置。applicationId这个DSL用于修改它们的applicationId，resValue支持res/values下的资源定义，与之前的buildConfigField区别是字符串无需加转义后的双引号。这里是app_name，所以app的应用名称也会被修改

productFlavors {  
    version1 {  
        applicationId "com.renyu.gradledemo.v1"  
        resValue "string", "app_name", "版本1"  
    }  
    version2 {  
        applicationId "com.renyu.gradledemo.v2"  
        resValue "string", "app_name", "版本2"  
    }  
}  

自定义apk文件输出路径及apk文件名

image.png

我希望可以像上图一样自定义apk的文件路径以及名称，这个也很简单，直接看代码

applicationVariants.all { variant ->
                variant.outputs.each { output ->
                    output.outputFile =
                            new File(rootProject.ext.appReleaseDir + getDate() +
                                    "_v" + rootProject.ext.defaultConfig.versionName +
                                    "_" +
                                    variant.productFlavors[0].name +
                                    rootProject.ext.appSuffixName)
                }
            }

new File中的内容就是我们的路径跟文件名，这个相信大家都能理解。我们在之前的config.gradle中新增一个appReleaseDir作为文件目录，然后用打包时间+版本号+渠道名称+文件后缀名作为文件名
config.gradle新增内容如下

    appReleaseDir = 'C:\\Users\\renyu\\Desktop\\'
    appSuffixName = "_release.apk"

build.gradle中的getDate()方法

def getDate()  {
    def date = new Date()
    def formattedDate = date.format('yyyyMMddHHmm')
    return formattedDate
}

NDK篇

abiFilters可以优先适配需要适配的cpu，其他做兼容处理。
如本例我们放置了armeabi、armeabi-v7a、x86三种类型CPU的so，其他的就让手机自己去做兼容处理去了

ndk {
    //选择要添加的对应cpu类型的.so库。
    abiFilters 'armeabi', 'armeabi-v7a', 'x86' // 还可以添加 'armeabi-v8a', 'x86_64', 'mips', 'mips64'
}

其他

莫名的抽风

之前在使用听云进行监控的时候，遇到一个很尴尬的事情：我仅仅在其中一个项目里面部署了听云，为什么在其他项目里面会出现听云的类找不到的错误呢？

java.lang.NoClassDefFoundError: com.networkbench.agent.impl.instrumentation

这时候无论你将全部听云配置都删除或是在.gradle里面将听云引用删除，都无法解决这个问题，这个就是android studio缓存的问题。那么怎么才能清理缓存呢？其实很简单，看图，在"file"菜单下有一个"Invalidate Caches / Restart"，只要重启这个就行了

Invalidate Caches / Restart

build文件夹无法删除

我们在执行build或者clean的时候，会遇到Build文件夹不能删除的情况。这时候我一般使用360去手动强制删除，但是有没有其他工具可以更加直接方便地去做这些事情呢？答案是肯定的。这里我推荐使用LockHunter——一个极简单的文件解锁工具，它可以删除一些被阻止的文件。

LockHunter

当然本文不会教你如何使用这个软件，而在于如何在控制台执行其提供的相关命令操作符
LockHunter.exe [/unlock] [/delete] [/kill] [/silent] [/exit] [file_or_folder_path]

• file_or_folder_path 文件路径，文件夹或路径的前导部分。例如 K:， C:\Program Files
• /unlock或-u 解锁file_or_folder_path。它关闭从file_or_folder_path开始的files\文件夹的所有句柄，并卸载位于从file_or_folder_path开始的files\文件夹中的.dll。
• /delete或-d 解锁并删除file_or_folder_path。如果file_or_folder_path是路径的部分名称（例如“C:\ Docu”是“C:\Documents and Settings”的部分名称），则从file_or_folder_path开始的所有文件和文件夹将被删除。注意，如果从file_or_folder_path启动进程，它们将阻止删除文件夹\文件。使用/kill参数强制终止这些应用程序。
• /kill或-k 终止从file_or_folder_path启动的所有应用程序 。如果file_or_folder_path是路径的部分名称（例如“c:\Docu”是“C:\Documents and Settings”的部分名称），则从file_or_folder_path字符串开始启动路径的所有进程将被终止。
• /silent或-sm 不会显示GUI。程序以静音模式启动，执行一个传递的命令（例如/unlock）并终止。
• /exit或-x 当所有操作完成时自动退出。此选项可能仅在您希望看到GUI，所有显示的警告但不希望手动按下“退出”按钮时才需要。
  下面演示一下如何删除根目录下的build文件夹与app模块下的build文件夹

task cleanRootBuildDir(type: Exec) {
    ext.lockhunter = "D:\\LockHunter\\LockHunter.exe"
    def rootBuildDir = file("../build")
    commandLine "$lockhunter", "/delete", "/silent", rootBuildDir
}
task cleanAppBuildDir(type: Exec) {
    ext.lockhunter = "D:\\LockHunter\\LockHunter.exe"
    def appBuildDir = file("build")
    commandLine "$lockhunter", "/delete", "/silent", appBuildDir
}

分别在控制台中执行gradle cleanRootBuildDir或者gradle cleanAppBuildDir即可。注意网上有很多介绍android studio中如何使用LockHunter的文章，但是他们的命令行执行语句都是错的

参考文章

Android layout用gradle分包
Gradle之dependencies
Gradle配置dependencies
productFlavors 实现多渠道多版本打包调试
发布Android studio项目到本地Maven仓库
优雅的发布Android开源库(论JitPack的优越性)
Gradle配置最佳实践
GRADLE构建最佳实践