何为增量编译？在讲增量编译时首先先介绍介绍下全量编译。在增量编译诞生前每次的代码编译都是全量编译（Maven可以指定编译，不知道Gradle有没有这个功能没这样用过），所谓的全量编译通俗点来说就是项目里面的所有代码文件，不管有修改过的还是没修改过的，在每次构建的时候都会被重新编译一次。很明显的全量编译的弊端就是重复工作，编译慢编译时长长，随着项目规模越大，编译的时间会越长，因此增量编译的技术就发展起来了。增量编译是跟全量编译相对应的，有了增量编译技术后，项目的代码文件只会在第一次编译时会触发一次全量编译（当然这里说的只是一般情况，有其他特殊情况也是会触发全量编译的，譬如早期的注解处理器也是会触发Gradle的全量编译，这里不再做深入讨论），其他时候编译只会编被修改过的文件以及有相关依赖的文件，这样一来就可以大大的缩减了编译时长了。但是试想下，如果项目规模足够的庞大，项目的结构还有依赖关系足够的复杂，这样一来做一次全量的编译绝对是一件很痛苦的事情，即便是增量编译也有可能因为依赖关系复杂，从而导致每次参与编译的代码文件也很多，导致编译时长变长。在做Windows开发的时候，我们可以把复杂的模块拆分成一个个的DLL工程，从物理层做划分，从而规避由于项目过大而导致编译时长变长的问题。可惜谷歌并没为安卓提供类似的这种模块化开发能力，那有没有办法在项目足够庞大的时候也能缩短编译时长，提高编译效率呢？方法还是有的，那就是分布式编译，以前在做Windows开发的时候有一款VS插件叫IncrediBuild，IncrediBuild提供了一套分布式编译的能力，可以大大的缩减了编译时间，搜索了下目前根本没有基于Gradle的分布式编译插件，要实现基于Gradle的分布式编译那前提是要把Gradle的编译过程编译原理弄透，然后再寻找突破口实现分布式编译。
Gradle 3.4版本可以说是Gradle的一个里程碑版本，因为从3.4版本开始，Gradle也开始支持增量编译了，关于Gradle 3.4版本增量编译的更多介绍可以看这篇文章Incremental Compilation, the Java Library Plugin, and other performance features in Gradle 3.4。文章中官方也做了一组测评，从评测数据对比中，我们能很明显得看得出来，3.4的版本比起以前的版本在编译效率上确实有了很大的提升
其实Gradle的增量编译过程也是足够的复杂的，笔者这里打算用四篇文章来阐述下Gradle的增量编译原理，带大家搞懂整个编译过程
Gradle增量编译一前言
Gradle增量编译二增删修改文件查找
Gradle增量编译三代码依赖关系检索
Gradle增量编译四代码编译内幕
Gradle增量编译五编译结果存储
