Gradle中的差异化构建

gradle的依赖构建配置项常见的在项目中有

• compile 'com.github.bumptech.glide:glide:3.7.0'
• debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.4'
• releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'

一直没有深究过这些构建方式间的差异 实际上还有

• testCompile 'junit:junit:4.12'

• androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2' 以及

• providedCompile group: 'javax.servlet.jsp.jstl', name: 'jstl', version: '1.2'

• runtime group: 'mysql', name: 'mysql-connector-java', version: '5.1.42

• Apk（只在打包Apk包时依赖）

可以从资源和行为的方式将以上5中构建方式分为2类

• compile testCompile和 androidTestCompile

  以及

• debugCompile,releaseCompile

compile：将依赖构建进项目中，引用资源的源文件位于module-name/src/main/java/下，任何时候都会依赖，相对应的providedCompile：仅在编译时依赖，运行时不依赖 runtime：仅在运行时依赖

testCompile：构建的是本地单元测试，测试源处于module-name/src/test/java/目录下。 常见的，会在gradle中做如下配置

  dependencies {
   // Required -- JUnit 4 framework
   testCompile 'junit:junit:4.12'
   // Optional -- Mockito framework
   testCompile 'org.mockito:mockito-core:1.10.19'
}
复制代码

androidTestCompile：构建的是模拟器环境的单元测试，测试源处于module-name/src/androidTest/java/下。 常见的配置如下：

  dependencies {
    androidTestCompile 'com.android.support:support-annotations:24.0.0'
    androidTestCompile 'com.android.support.test:runner:0.5'
    androidTestCompile 'com.android.support.test:rules:0.5'
    // Optional -- Hamcrest library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // Optional -- UI testing with Espresso
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}
复制代码

debugCompile 和 releaseCompile从行为上说和我们构建的环境相关，是debug还是release环境，区别是如果项目中依赖的模块仅仅声明了debugCompile 那么在构建release包的时候将编译不通过，原因在于release的task不会将仅声明debugCompile的依赖构建进工程，导致找不到依赖。

注意：Android Studio 3.X开始使用了新的指令，原来的很多被弃用了，总的来说是为了加快构建编译速度。

最后说一下mock的问题，写过单元测试的同学都知道，一件很痛苦的事是mock不到android package下的方法，导致单元测试无法进行。好在官方指了一条路，

Mockito

You can use a mocking framework to stub out external dependencies in your code, to easily test that your component interacts with a dependency in an expected way. By substituting Android dependencies with mock objects, you can isolate your unit test from the rest of the Android system while verifying that the correct methods in those dependencies are called. The Mockito mocking framework for Java (version 1.9.5 and higher) offers compatibility with Android unit testing. With Mockito, you can configure mock objects to return some specific value when invoked.

参考：

• unit-testing-support
• studio-test
• mocking-dependencies
• www.jianshu.com/p/341744b98…