【Android】api与implementation的区别

一、从3.4版本的gradle开始,compile已经被api与implementation取代,官网也给出了三者之间的区别:

从官网介绍可以看出,implementation可以让module在编译时隐藏自己使用的依赖,但是在运行时这个依赖对所有模块是可见的。而api与compile一样,无法隐藏自己使用的依赖。
具体通过例子来看,下图为项目结构:

app依赖模块mylibrary1、mylibrary1依赖模块mylibrary3
mylibrary1如下:

package com.example.mylibrary1;
/**
 * @author heshufan
 * @date 2018/8/9.
 */
public class MyClass1 {
    public static String  get(){
        return "MyClass1";
    }
}

mylibrary3如下:

package com.example.mylibrary3;
/**
 * @author heshufan
 * @date 2018/8/13.
 */
public class MyClass3 {
    public static String get(){
        return "MyClass33";
    }
}

当mylibrary1 使用api依赖mylibrary3时,

api project(':mylibrary3')

在App中可以直接调用MyClass3类,也就是依赖可以传递。

package com.example.heshufan.learnapiandimp;
import com.example.mylibrary1.MyClass1;
import com.example.mylibrary3.MyClass3;
public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        MyClass1.get0();
        MyClass3.get();
    }
}

当mylibrary1使用implemention依赖mylibrary3时,

implementation project(':mylibrary3')

在App中,无法直接调用mylibrary3

从上面的例子可以看出,在多module中,implementation确实可以起到隐藏依赖的作用,网上很多的文章都只讲到了这点,那么这样做的目的是什么呢?其实这并不是Google设计implemention与api的目的,因为官方文档中说这样设计的目的在于减少build的时间,那么implemention是如何减少build time的呢?

二、我们再新建一个module:mylibrary4,现在的项目结构如图:

那么现在的项目层级如下图所示:

1、如果mylibrary3使用api依赖mylibrary4,那么当mylibrary4发生变化时,编译需要重新编译mylibrary4、mylibrary3、mylibrary1;
2、如果mylibrary3使用implemention依赖mylibrary4,那么当mylibrary4发生变化时,编译需要重新编译mylibrary4、mylibrary3,这个时候不需要编译mylibrary1,这样就可以节约build time;

为此我验证了两种依赖下项目的build time,每次重新编译前clean project,改变mylibrary4,然后rebuild project,再查看build time。

使用implemention的build time:

使用api的build time

可以看到api的build time比implemention多了1秒多,多次运行都多了1秒多,这还是在module比较小的情况下。如果包比较多,比较大,那么可以节约的时间是非常可观的。
总结起来:如果api依赖,一个module发生变化,这条依赖链上所有的module都需要重新编译;而implemention,只有直接依赖这个module需要重新编译。

三、现在在回过头来看一下依赖传递的问题,之前验证了使用implemention,app不能拿到MyClass3,这是在本地依赖的情况下,而现在的模块化开发多采用远程依赖的模式进行合作。那么如果采用maven远程依赖呢?
同样采用之前的例子,我们新建一个module :mylibrary2

我们将其上传到我们的本地maven

最后在mylibrary1中利用implemention依赖mylibrary2

    //mylibrary1
    implementation 'com.example:mylib:1.0.3'

然后我们再将mylibrary1上传到本地maven,然后在app中远程依赖mylibrary1

    //mylibrary2
    implementation 'com.example:myClass2:1.0.0'

也就是app远程implementation mylibrary1,mylibrary1远程implemention mylibrary2,这时候app就可以直接拉到mylibrary2中的myClass2类(命名不规范,别学我)

而如果app本地implementation mylibrary1,mylibrary1远程implemention mylibrary2,这时候app则不能获取到mylibrary2中的myClass2类,依然起到了依赖隔离的作用。

由以上可以看到在全部远程依赖模式下,无论是api还是implemention都起不到依赖隔离的作用。不过,在远程依赖模式下,依赖的一个模块如果版本发生变化,implemention与api的构建速度谁快谁慢还需要进一步研究。

综上,在多层次模块化(大于等于三层module)开发时,如果都是本地依赖,implementation相比api,主要优势在于减少build time。如果只有两层module,api与implemention在build time上并无太大的差别。

  • 6
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值