关于gradle的implementation、api和compileOnly三种依赖方式

  • implementation: 参与编译和打包,依赖的包不对其它工程开放
  • api : 参与编译和打包,依赖的包对其它工程开放
  • compileOnly: 参与编译但不参与打包,依赖的包对其它工程不开放。如果整个工程紧使用comileOnly方式依赖某个包,在使用时编译不报错,但运行的时候会找不到该类。如果有其它moudle使用了implementation或者api 方式依赖,那么运行时就不会报错,最终依赖的是其它module所导入的包

一 场景主工程app依赖于moduleB,moduleB依赖于Gson包,在app当中调用Gson的方法

app:

implementation project(path: ':B')

方式一:B使用implementation依赖:

 implementation 'com.google.code.gson:gson:2.6.2'

效果:在工程A中调用Gson方法会编译不通过

关于gradle的implementation、api和compileOnly三种依赖方式_第1张图片

  • 结论:implementation不对外提供依赖的包,参与编译打包

方式二:B使用api依赖:

 api 'com.google.code.gson:gson:2.6.2'

效果:app中调用Gson方法正常编译并且运行

关于gradle的implementation、api和compileOnly三种依赖方式_第2张图片

  • 结论:api对外提供工程所依赖的包,并且参与编译和打包

方式三:B使用compileOnly依赖:

compileOnly 'com.google.code.gson:gson:2.6.2'
  • 结论:如方式一一样编译不通过,说明工程B依赖的Gson不对外开放,compileOnly不对外提供依赖的包

二 场景app使用compileOnly方式依赖Gson,注:此时工程A没有依赖B

app:

compileOnly 'com.google.code.gson:gson:2.6.2'

在工程A当中使用Gson

关于gradle的implementation、api和compileOnly三种依赖方式_第3张图片

编译正常通过,打包运行找不类:

关于gradle的implementation、api和compileOnly三种依赖方式_第4张图片

  • 结论:compileOnly参与编译不参与打包

问题一:app依赖于B并使用compileOnly依赖Gson包,同时B中使用implementation依赖Gson包,在app当中使用Gson,那么效果怎样?

效果:正常编译和运行

app使用了compileOnly方式依赖了Gson包,Gson参与了编译,所以app当中使用Gson能够正常编译

那么为何能够正常运行呢?

B当中使用implementation方式依赖了Gson,虽然在编译时不提供对外依赖给app,但打包时将Gson打包到了apk中,所以app运行时可以找到Gson包,故运行不报错

思考,compileOnly存在的意义?

我们在使用第三方包的时候经常面临包冲突的问题,如果我们提供包给别人用,如何来避免使用人员的包冲突问题呢?

同样以Gson包为例,如果我们指定了我们module的Gson包版本为2.6.1使用如下两种方式依赖

//    implementation 'com.google.code.gson:gson:2.6.1'
//        api 'com.google.code.gson:gson:2.6.1'

那么使用我们module开发人员,也依赖了一个 Gson包,版本为2.6.2

//    implementation 'com.google.code.gson:gson:2.6.2'
//        api 'com.google.code.gson:gson:2.6.2'

这样一来就打包运行时,apk当中就存在了两个gson包,不但使apk体积增大,还可能造成app运行报错

如何避免?

如果我们有一种方式,在我们写自己的moudle时能够正常调用Gson包但不指定版本,具体版本由使用者来指定,这样就能避免最终app当中Gson版本不同的问题,compileOnly占位依赖的方式正好满足这一需求

你可能感兴趣的:(Android构建配置,android,gradle,安卓)