（一）依赖
首先了解gradle中的六种依赖：
1） compile：它是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中。
2） provided：它是对所有的build type以及favlors只在编译时使用，类似eclipse中的external-libs，只参与编译，不打包到最终的apk。
3） apk：只会打包到apk文件中，而不参与编译，所以不能在代码中直接调用jar中的类或者方法，否则编译时报错。
4） test compile：它仅仅是针对单元测试代码的编译以及最终打包测试apk时有效，而对正常的debug或者release apk包不起任何作用。
5） debug compile：它仅仅针对debug模式的编译和最终的debug apk打包。
6） release compile：仅仅针对release模式的编译和最终的release apk打包。
首先知道gradle在打包的时候有debug和release两种版本，debug使用默认的debug签名。
经常使用的就是compile和provided，区别在于provided依赖的jar并不会打包到apk中去。从字面意义上看，provided表示已提供，也就是说运行环境中已经有相应的库了，不需要再把这个依赖的库打包进去了，否则可能会引起冲突。举个例子，多个module都引用了一个库，而主module又引用了别的module（如环信的easeui），这样二次依赖就会产生冲突。解决方案就是easeui的gradle文件中将相应的库依赖改为provided，这样最终打包的apk中只有一个jar，也就不会出问题。
Gradle3.0（项目gradle里依赖的gradle版本）之后依赖部分有了较大改变：
api替代compile, compileOnly替代provided, runtimeOnly替代apk， 与之对应的还有testApi,testCompileOnly等。
另外，还提供了一个implemention。在此之前，gradle提供的module依赖是支持间接依赖的，也就是说B依赖C，A依赖B，那么A也能看见C，能访问C。这样的话如果C发生改变需要重新编译，那么AB都要重新编译。虽然A不一定引用了C，但是他有可能引用C，所以保险起见gradle让A也重新编译。
而implemenets则保证了本方依赖的module不会暴露给依赖自己的module。还是上面那个例子，把B comoile C换成B implemention C，则A无法访问到C，C重新编译时只会通知B重新编译。当然了，这个关键字并不只用于project依赖，理解他的意思就可以用于库依赖。
（二）
make project:重新编译更新的文件
clean/rebuild:删除所有已编译出的东西，重新编译(???)
build apk:生成apk，若未编译则编译。