Gradle作为一个新的构建系统，无疑在灵活，扩展，跨平台等各方面都表现得非常优秀，然而，它也有一点备受吐槽，就是速度慢。以下为本人使用gradle过程中，几次加快gradle构建速度的经验之谈。
本文原创。
转载请注明CSDN博客出处：
http://blog.csdn.net/maosidiaoxian/article/details/49583215
1，开启守护进程。
这一点在许多问答网站，博客等，都会提到。通过开启守护进程，下一次构建的时候，将会连接这个守护进程进行构建，而不是重新fork一个gradle构建进程。通过在~/.gradle（如果是windows下，则为用户目录下的.gradle文件夹，如果配置过 GRADLE_USER_HOME，则为该目录）中编辑（如果没有则创建）gradle.properties，加入以下配置，可以让所有项目在构建时都开启守护进程：
org.gradle.daemon=true
2，开启并行编译
这一点同上，也是常见的加快编译速度的方法。在多项目（或多模块）编译时它会很有用。同样在~/.gradle/gradle.properties中加入：
org.gradle.parallel=true
3，使用新版的gradle和android gradle plugin。
然而，在加上这两行之后，随着项目开发的逐渐复杂，引入的库也越来越多，项目本身也要增加一些productFlavor，速度又开始慢起来。后来Android Studio升级，Gradle升级，看到Gradle 2.4的升级说明上提到提高了gradle的构建速度，于是用了新版的Gradle，果然提高了些许速度。
编辑项目根目录下的build.gradle，把android gradle plugin更新到新版本：
classpath 'com.android.tools.build:gradle:1.3.0'
如果是使用本地的gradle，则下载新的版本，并且更新新版本的gradle到path的环境变量中。如果是使用gradlew构建，则编辑项目根目录下的gradle/wrapper/gradle-wrapper.properties，把gradle改为2.4或更新的版本。
distributionUrl=https\://services.gradle.org/distributions/gradle-2.4-all.zip
4，命令行构建。
在Android Studio中，点击运行时它是将当前的构建任务加入到队列中。也就是，如果你改过build.gradle的文件导致它在同步脚本时，就必须等到这个任务完成之后才会执行你刚才的构建任务。作为命令行控的我，首先还是用命令行构建了。
./gradlew assembleRelease
上面的任务还可以简写为：
./gradlew aR
由于我这里的项目中因需要而创建了几个productFlavor：Develop, Test, Official。所以如果使用./gradlew aR的话，它会同时构建这三个的release版本。而实际上，我在开发的时候只需要构建Develop这一个，所以命令改为如下：
./gradlew aDR
5，屏蔽不必要的productFlavor
在使用命令行的构建过程中，我发现尽管我只是要构建Develop版本，但是它还是会去解析每一个productFlavor的依赖，并且在依赖上卡很久。所以在构建时先注释掉了其他两个pruductFlavor，果然在解析依赖的这一步就节省了一半以上的时间。在不clean的情况下，之前构建一次接近三分钟，现在不到两分钟。
6，使用离线模式。
我发现在构建过程中，除了修改了java文件然后在multldex时有点耗时之外，最大的耗时都在于resolving dependencies，也就是解析依赖的这一步。而我的项目这时候的依赖应该都在本地中有缓存了。所以使用--offline，让它不去联网检查更新。
./gradlew aDR --offline
因为是构建过的，所以只需要3.846秒。而即使是clean，构建的时间也只需要47.175秒（并不是每一次都是这个时间，有时间会比较大，多构建几次会快一些）。
7，不使用snapshot依赖仓库
现在的速度已经和以前一样快了，但是在Android Studio中直接点运行，总比在命令行执行./gradlew aDR --offline && adb install -r app/build/outputs/apk/xxxxxx.apk要更方便些，而如果在Android Studio中开启offline mode的话，下次更新依赖又要去取消掉它或者在命令行下更新一次依赖。所以我决定再找找gradle不开离线模式下变慢的原因。
命令行下执行：
./gradlew aDR --info
让gradle在构建过程中打印消息日志。
结果发现，有一些android support库，它会去我声明的一个SNAPSHOT仓库中去找，因为找不到，所以在这一步会耗时很多。特别是我有3个productFlavor的情况下，每一个flavor的依赖都要去解析一遍，这样就要消耗三倍的时间。
之所以会声明这个SNAPSHOT仓库，是因为项目中用到了JakeWharton大神的ViewPagerIndicator，而他的这个库已经两年没维护，里面有几个bug没有修复。我在修复之后，又加了一点新的功能，就准备发布到2.5版本，由于还没怎么测过，所以只是作为SNAPSHOT版本发在了oss.jfrog.org上。于是切换到ViewPagerIndicator项目，把我的改动发到了jcenter中，然后项目的依赖改为2.5版本而不是2.5-SNAPSHOT，然后在依赖库声明为，把这个依赖仓库给注释掉。
先构建一下，下载ViewPagerIndicator 2.5的依赖。然后我们再运行一遍，看一下速度：
./gradlew aDR
现在解析依赖变得很快，一秒不到就完成了。由于是编译过的，所以整个过程很快，3.092秒，和offline模式下相同（这点时间上的差别，并不能因此说它比offline下更快，即使是相同的构建，偶尔也会有一点时间上的差别）。
再看一下clean后再编译的情况：
./gradlew clean aDR
只需要47.912秒。已经和--offline下一样了。
从以上过程中可以总结出加快构建速度的技巧如下：
开启守护进程，开启并行编译，使用新版本的android gradle plugin, 使用新版本的Android Studio（它会使用新版本的Tools api去调用gradle），使用新版本的Gradle，使用命令行构建（如果你实在等不级Android Studio中还未执行完的其他任务），构建时减少productFlavor，避免使用SNAPSHOT版本及使用SNAPSHOT仓库，使用离线模式（如果允许），如果没必要则不需要在构建时进行clean。
据说，facebook出了一个新的构建系统，可以构建android, ios, cpp, java, python, go等项目，支持linux, mac（windows?呵呵）。还据说，微信也在使用这个构建系统。接下来我要去了解一下它了。