debugImplementation、releaseImplementation、testImplementation

依赖配置有：implementation、provided、api、apk、compileOnly、runtimeOnly、渠道名+Compile，
差异主要在于构建内容和参与构建的时机，多样的配置方式满足了开发者的花样需求，具体区别如下：

参考：Gradle3.0新指令api、provided、implementation等对比

api （compile）

依赖向上传递

若A api B, B api C，C module对A module可见

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+api/compile指定，比如debugApi、releaseApi、testApi

implementation （新指令: 具备依赖可见性）

依赖不向上传递

若A implementation B, B implementation C，C module对A module不可见

若A implementation B, B api C，C module对A module可见

功能同api，区别仅仅是增加了依赖可见性

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+implementation指定，
比如debugImplementation、releaseImplementation、testImplementation。

如果想在debug模式中使用，release中不使用某个库，可使用这种方法：

dependencies {
    //实现
    debugImplementation 'com.github.DingProg.NetworkCaptureSelf:library:v1.0.1'
    //空实现
    releaseImplementation 'com.github.DingProg.NetworkCaptureSelf:library_no_op:v1.0.1'
}

参考： DingProg /NetworkCaptureSelf

compileOnly（provided）

只在编译时有效，不会参与打包

主要是为了方便程序编译通过的，不会打包到apk中，使用场景：android系统有这个API，但编译时需要引入才能构建通过，比如系统的APK依赖framework.jar、gson库等

若A implementation C，打包后apk（A + C）；

而A compileOnly C，打包后apk（A）；

该指令实质：A module假装依赖了C module通过欺骗编译器编译时检测以避免java.lang.ClassNotFoundException编译报错

使用情形

A implementation C，B implementation C，打包时A module生成aar（A + C），B module生成aar（B + C）

若改成A implementation C，B compileOnlyC，打包时A module生成aar（A + C），B module生成aar（B）

最终apk包（A + B + C），结果一致

虽然aar（B）不真实依赖C module，但B module确实用到了C module的api。

没有运行时错误的原因：aar（A + C）与aar（B）合并生成apk，B module运行时找到并调用aar（A + C）中的C module

runtimeOnly（apk）

只在生成apk的时候参与打包，编译时不会参与，很少用。不能在代码中直接调用依赖包的代码，否则会在编译时出错。

debugImplementation（debugCompile）

debugImplementation 只在debug模式的编译和最终的debug apk打包时有效。

releaseImplementation（releaseCompile）

releaseImplementation 仅仅针对release 模式的编译和最终的release apk打包。

androidTestImplementation（androidTestCompile）

androidTestImplementation 只在单元测试代码的编译以及最终打包测试apk时有效。

debugImplementation 依赖的常见库：

开发助手： didi DoraemonKit

内存泄漏检测： square /leakcanary

性能监控: Kyson /AndroidGodEye

jetpack发布相同包名的module，使用debugImplementation、releaseImplementation

1.两个module一样的包名

2.发布后两个library怎么区分依赖

如何通过Android Studio将项目发布到GitHub并同步到JitPack仓库？

jetpack官网

android集成jetpack官网指南

按照步骤上传后，如何引入呢？

先按照以下引入：

implementation 'com.github.Ablexq:HttpHelper:Tag'

报错：

* What went wrong:
Execution failed for task ':app:checkDevelopDuplicateClasses'.
> 1 exception was raised by workers:
java.lang.RuntimeException: 
Duplicate class com.example.httphelplib.BuildConfig found in 
modules jetified-httphelplib-1.0.0-runtime.jar 
(com.github.Ablexq.HttpHelper:httphelplib:1.0.0) and 
jetified-httphelplib_no_op-1.0.0-runtime.jar 
(com.github.Ablexq.HttpHelper:httphelplib_no_op:1.0.0)
Duplicate class com.example.httphelplib.host.HostInterceptor 
found in modules jetified-httphelplib-1.0.0-runtime.jar 
(com.github.Ablexq.HttpHelper:httphelplib:1.0.0) and 
jetified-httphelplib_no_op-1.0.0-runtime.jar 
(com.github.Ablexq.HttpHelper:httphelplib_no_op:1.0.0)
Duplicate class com.example.httphelplib.log.CaptureInfoInterceptor
 found in modules jetified-httphelplib-1.0.0-runtime.jar
 (com.github.Ablexq.HttpHelper:httphelplib:1.0.0) and 
jetified-httphelplib_no_op-1.0.0-runtime.jar 
(com.github.Ablexq.HttpHelper:httphelplib_no_op:1.0.0)

Go to the documentation to learn how to 
<a href="d.android.com/r/tools/classpath-sync-errors">Fix dependency resolution errors</a>.

可看到httphelplib和httphelplib_no_op相同包名，不能共存，使用以下解决即可：

debugImplementation  'com.github.Ablexq.HttpHelper:httphelplib:1.0.0'
developImplementation  'com.github.Ablexq.HttpHelper:httphelplib:1.0.0'
releaseImplementation 'com.github.Ablexq.HttpHelper:httphelplib_no_op:1.0.0'