记录android导入依赖的一些事

1.implementation和api

implementation

Gradle 会将依赖项添加到编译类路径，并将依赖项打包到构建输出。不过，当您的模块配置 implementation 依赖项时，会让 Gradle 了解您不希望该模块在编译时将该依赖项泄露给其他模块。也就是说，其他模块只有在运行时才能使用该依赖项。
使用此依赖项配置代替 api 或 compile（已弃用）可以显著缩短构建时间，因为这样可以减少构建系统需要重新编译的模块数。例如，如果 implementation 依赖项更改了其 API，Gradle 只会重新编译该依赖项以及直接依赖于它的模块。大多数应用和测试模块都应使用此配置。

api

Gradle 会将依赖项添加到编译类路径和构建输出。当一个模块包含 api 依赖项时，会让 Gradle 了解该模块要以传递方式将该依赖项导出到其他模块，以便这些模块在运行时和编译时都可以使用该依赖项。
此配置的行为类似于 compile（现已弃用），但使用它时应格外小心，只能对您需要以传递方式导出到其他上游消费者的依赖项使用它。 这是因为，如果 api 依赖项更改了其外部 API，Gradle 会在编译时重新编译所有有权访问该依赖项的模块。 因此，拥有大量的 api 依赖项会显著增加构建时间。除非要将依赖项的 API 公开给单独的模块，否则库模块应改用 implementation 依赖项。

2.重复依赖

implementation 'aar1 1.0'
implementation 'aar2 1.0'

aar1 1.0 aar2 1.0都是以maven依赖的形式导入，aar2 1.0 中又y依赖了aar1 0.5，当两者都以maven依赖导入时会自动选择最高版本，当把aar1 替换为本地aar1 1.1依赖的模式时，此时就会编译不过，自动使用了aar2中依赖的aar1 0.5。此时想要正常编译通过有两种方法
1.exclude

implementation files('aar1 1.1aar')
    implementation (aar2 1.0') {
        exclude module: 'aar1_sdk'
    }

移除不需要的依赖模块
2.transitive

implementation files('aar1 1.1aar')
    implementation (aar2 1.0') {
       transitive = false
    }

不解析内部依赖

3.testCoverageEnabled

 buildTypes {
        debug {
            testCoverageEnabled true
        }
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

BuildType#testCoverageEnabled 配置 作用是 配置 是否为此 BuildType 编译类型 启用测试覆盖率报告 ;
配置该属性后，打包debug出的aar包使用时会报错
Failed resolution of: Lorg/jacoco/agent/rt/internal_8ff85ea/Offline;
打包release即可