记——加快gradle 构建速度的经验

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?呵呵)。还据说,微信也在使用这个构建系统。接下来我要去了解一下它了。

上一篇:Mybatis总结


下一篇:HTML5 div+css导航菜单