我自己比较喜欢传统的构建方式，但随着android的不断进步，只能切换到gradle来构建了。但gradle真的很不方便，往往只是修改其中的一个模块，就需要将其他的模块统一整理一下，有时候只是想测试一下，临时修改一下而已。
gradle的settings.gradle部分
所有需要的模块都需要include进去，如果模块没有进去，就会找不到。如果修改了某个字模块(A)的构建脚本，构建其他与这个子模块完全无关的模块(B,C,D等)的时候，也会检查这个模块(A)的脚本合法性.
我的单个gradle工程下面有很多模块，因为偷懒以及尽可能的适用性，很多项目的代码直接适用子模块的方式构建，但不同项目的版本号可能不是一样的，而有些部分真的是一些功能模块，是不需要版本号之类的。 在构建需要版本号功能的时候，我会在构建的时候，传入正确的版本号，比如：
gradlew bundleRelease -Pversion_code=1 -Pversion_name=0.0.1
在构建功能模块的时候，是完全不需要参数的，然后在功能模块下，适用下面的命令:
gradlew build
这样是会失败的，因为在构建的预处理阶段，会去检查项目的代码，然后发现参数没有定义。
如果象我这样，每个模块，每个项目都是使用git+repo来管理的话，为了单独一个项目或者子模块的参数，需要更新几乎所有项目的脚本。看着我的整个项目的几百个git,实在太无语了。
gradle构建过程中的依赖部分
gradle 在每次构建过程中，会自动检查依赖的版本，如果版本号使用’+’的方式，则会使用最新的版本。 而我有些项目的依赖比较多，于是就发生各种各样古怪的事情：
某天我构建出来的包突然比前一天的包大了近20MB，这让我难以接受，毕竟除了资源，我原来的包只有10多MB,然后不断的检查依赖和最终包内容， 发现facebook的sdk在更新中加入了某个国际化的utf-8的表情支持之类的。然后只好固定facebook的版本号才得以解决
某天我突然构建失败，提示什么某些依赖无法找到，然后各种详细日志检查，发现是sdk提供方的服务器挂了，返回502了，又赶上对方周末或者休假， 过几天又自己好了。
模块之间的依赖
几个模块， A(native,build)，B，C，A是项目的主体，包含最终的打包动作(A.build)和native构建部分(A.native)，B在构建的时候依赖 A的java编译部分， C是动态模块部分，依赖B的java编译部分，并最终作为资源放到A的资源目录中。
对于传统的makefile部分，只需要将各部分的动作作为任务依赖即可自动跟踪检查，而使用gradle，尤其尽量复用插件的情况下， 就必须进行各种的hook或者注入。于是我不得不在每个项目或者模块中，在任务添加的时候，动态的添加某部分的依赖。
构建过程
在使用第三方代码的时候，最好祈祷构建脚本需要的gradle版本，android工具的gradle版本和现有的没有太大的冲突， 不然，又要找资料，找方案，折腾好半天环境。
我希望的构建系统是尽可能的稳定的，在项目的开发，迭代过程中没有太大的变化，这样一旦开发环境搭建 完成，就不需要反复的确认环境问题。而这一点上，gradle显然有各种问题，这也许是因为我没有对gradle进行 详尽仔细的学习的原因，但gradle的文档也太多太长了，再加上不同版本的变化，再加上google的插件 又比较随意，真的很让人头疼啊。
回头还是将android的源代码下载下来看看大家都是如何使用gradle的吧。