GRADLE 构建最佳实践

随着谷歌对Eclipse的无情抛弃和对Android Studio的日趋完善，使用gradle构建Android项目已经成为开发者的一项必会良技。那么，问题来了，采用什么样的姿势才能让项目开发构建过程高潮迭起，精彩不断呢？

其实网上有很多关于gradle的文章，gradle官方和谷歌也提供了详细的文档和教程，可素，当你在构建过程中遇到一些问题或者有特殊的爱好（需求）的时候，这些东西未必能帮（mei）上（shen）什（me）么（niao）忙（yong），然后就是一顿FQ找谷歌蜀黍约约约，去stackoverflow上各种搜刮问大神，最后解决了。即使没有真的解决那么就忍了。

那怎么行？是可忍孰不可忍，奇技淫巧必须有。所以就会有这样一篇文章，我在这里不讲原理，因为我知道很多人明白辣么多的底层原理，仍然撸不上好代码，做不成好项目，出不了好产品，自然也就过不好这一生咯。

我们先从GRADLE构建的时间花销开始谈起。

加速篇

GRADLE的构建过程通常会比较漫长，一个中等项目，10M左右大小的app，一次完整构建大概在5分钟左右，是不是很吓人，当然，如果是在调试阶段，采用Android Studuo 2.0，默认提供的Instant Run方式，每次修改都不会重新构建项目，从而加快了构建过程。恩，这是另一个故事，这里，我们先谈谈GRADLE脚本的加速姿势。

一般来说，GRADLE一次完整的构建过程通常分成三个部分，初始化，配置和执行任务，那么我们可以考虑从这三个部分分别尝试优化。

使用daemon

构建初始化的很多工作是关于java虚拟机的启动，加载虚拟机环境，加载class文件等，如果这些动作交给一个单独的后台进程去做，那么，第一次初始化之后的修改代码再构建是不是可以节省很多时间呢？答案是肯定的，通过在gradle.properties加入这样一句来开启，如果想让修改全局所有项目都生效，那么修改这个文件~/.gradle/gradle.properties

按需配置

配置有一种方式是按需配置，目前还在试验孵化阶段，所以默认是关闭的，可以通过在gradle.properties加入这样一句来开启

依赖库使用固定版本

项目开发过程中，难免需要用到三方库，这就形成了项目之间的依赖关系，GRADLE提供了多种集成三方库的方式，提供了很方便的项目依赖管理，本地库，库工程，maven库全支持。既然用到库，就会遇到库版本的问题和升级问题，其中maven库的依赖管理支持一种动态版本的方式，也就是说，GRADLE可以做到不依赖具体某个版本的库，而是每次从repo拉取最新的库到本地做编译。具体使用是这样的：

拿gson库举例，如果依赖2.2.1这个版本，可以在build.gradle文件里这样写

如果不想依赖具体的库，想每次从maven repo中拉取最新的库，那么，可以写成这样：

也可以写成这样

甚至可以这样

其中含义相信不用我解释，大家也看得明白吧。

用”+”来通配一个版本族，这样有个好处是maven上有新库了，不用你操心升级，GRADLE编译的时候自动升级了，但是带来了两个坏处，一是，有可能新版库的接口改了，导致编译失败，这个时候需要修改代码做升级适配；更大的坏处是，每次GRADLE编译完整的项目，都会去maven上试图拉取最新的库，这样，拖慢了编译速度，尤其在网络非常差的时候，所以，为了构建速度，建议写死依赖库的版本号。

升级到最新的GRADLE和JDK

有一个很通俗的道理是，发展的东西会越来越好，最新版的GRADLE和JDK往往是性能最好，运行最流畅最快的，所以，升级吧，JDK的升级这里不说了，具体看Oracle的官方文档。这里说说GRADLE的版本升级，GRALDE采用了一种叫做wrapper的方式，可以做到每个项目独立使用其自己的GRADLE版本，这样做的好处不言而喻，每个项目的构建环境独立，互不影响。但为什么会出现这个东西，我的猜想是因为GRADLE发展太快，新旧版本之间很难兼容。如果你有多个项目都采用GRADLE构建，假设都用同一个全局的GRADLE，那么当这个GRADLE升级后，所有的项目可能都会编译失败，你得一个一个改配置，那么，下次再升级，同样的流程的再走一遍，是不是很烦。采用wrapper的方式很好的解决了这个问题，每个项目采用独立的GRADLE版本，互不影响，如果你只想升级其中一个，你改这一个项目的GRADLE wrapper就好了。在你的项目目录下找到这个文件gradle/wrapper/gradle-wrapper.properties并修改distributionUrl=https\://services.gradle.org/distributions/gradle-2.11-all.zip到你想升级的版本就可以了。

减少编译脚本中的I/O操作

有时候，编译脚本中会有一些代码做动态信息的获取，比如想从git中获取一个数字作为版本号

其实这个操作主要是为了在构建的机器上为了发布版本而做的，日常环境研发调试无需这样，所以可以优化成如下方式：

并行构建模块化项目

将你的项目拆分成多个子项目并开启并行构建也是一个不错的主意，比如将相对独立的模块拆分成独立的库工程(Library projects)，主工程(Application project)依赖这些库工程，这样的话，开启并行构建才会发挥作用。并行构建开启方式是修改文件gradle.properties，加入如下行：

基础配置篇

全局基础配置管理

设置全局编码

如果导入一个windows下编写的项目，而代码中有中文注释，采用GBK, GB18030等编码方式时，编译会报错，可以采用如下方式统一项目的编码

设置全局编译器的版本

如果编程过程中采用了新版JDK（比如1.7）才支持的特性(比如new HashMap<>这样的写法)，而编译的时候默认是旧版的JDK(比如1.6)，这个时候编译会报错，采用如下方式可以指定用哪个版本的编译器编译，前提是JAVA_HOME指定的JDK是大于等于新版JDK的哦^o^，其他和java编译器相关的也可以在这里配置

如果不想全局生效，可以将tasks.withType(JavaCompile)放入某个子项目中。

配置签名信息

签名信息属于敏感信息，建议不要写死放到gradle脚本中，而是写到一个单独的配置文件里，而且这个配置文件不要同步到版本管理系统上，而是由本地维护，防止在版本管理平台上泄漏敏感信息。建议签名信息内容写到gradle.properties或者local.properties文件里，这样，gradle脚本可以直接引用，如果是放在一个自定义的文件中，gradle脚本需要提供相应的代码来读取文件的内容。

文件内容参考如下：