这里有几个依赖相关的概念理解起来非常有意思，其中之一就是配置的概念，其解释了compile关键字。
配置
有时候可能你不得不和一个在特定设备上工作的SDK打交道，比如特定厂商的蓝牙SDK。为了能编译该代码，你需要将SDK添加至编译类路径。你并不需要添加SDK到你的APK中，因为其早已存在于设备中，这就是所谓的依赖配置。
Gradle将多个依赖添加至配置，并将命名为集文件。下面是Android应用或依赖库的标准配置：
- compile
- apk
- provided
- testCompile
- androidTestCompile
compile是默认配置，在编译主应用时包含所有的依赖。改配置不仅会将依赖添加至类路径，还会生成对应的APK。
如果依赖使用apk配置，则该依赖只会被打包到APK，而不会添加到编译类路径。Provided配置则完全相反，其以来不会被打包进APK。这两个配置只是用于JAR依赖。
最后，testCompile和androidTestCompile配置会添加用于测试的额外依赖库。在运行测试相关的任务时，这些配置会被使用，并且再添加如JUnit或Espresso测试框架时，特别有用。如果你只希望在测试APK时使用这些框架，那么就不会产生APK。
除了这些标准配置外，Android插件还针对每个构建variant都生成一份配置，使其添加依赖配置化为可能，例如debugCompile，releaseProvided等。当你只想在debug构建中添加logging框架时，这会非常有用。这个在以后会说到。
语义化版本
版本化时依赖管理的重要部分。将依赖添加到JCenter等依赖仓库，时预定遵循了一套版本化规则，我们称之为语义化版本。在语义化版本中，版本数字的格式一般为major，minor，patch，数字则按照下列规则一次增加：
- 当做不兼容的API变化时，major版本增加。
- 当以向后兼容的方式添加功能时，minor版本增加。
- 当修复一些bug时，patch版本增加。
动态化版本
在某些情况下，你可能希望在每次构建你的应用或者依赖库时，都能够获取到最新的依赖。
要想做到这一点，最好的实现方式是使用动态化版本。动态化版本的使用方式有很多种，例如：
dependencies{
compile ‘com.android.support:support-v4:22.2.+’
compile ‘com.android.support:support-v7:22.2+’
compile ‘com.android.support:recyclerview-v7:+’
}
第一行，我们告知Gradle获取最新的patch版本。第二行，我们希望能获取每一个最新的minor版本，并且minor版本至少是2。最后一行，我们告知Gradle获取依赖库的最新版本。
在使用动态版本化时，需要格外小心。如果你允许Gradle获取最新的版本，则可能Gradle获取的依赖版本并不稳定，他会导致构建中断。更糟糕的时，其会导致在构建服务器上和自己的机器上运行着不同版本的依赖，从而导致应用程序的行为不一致。
未完。。。
