深入理解编译注解(三)依赖关系 apt/annotationProcessor与Provided的区别

前端之家收集整理的这篇文章主要介绍了深入理解编译注解(三)依赖关系 apt/annotationProcessor与Provided的区别前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

前言

网上有很多朋友在问: apt/annotationProcessor与Provided 都是只编译并不打入apk中,他俩到底有什么区别呢?所以我就把自己所了解的与大家分享一下。

正文

编译关系 apt/annotationProcessor

只在编译的时候执行依赖的库,但是库最终不打包到apk中,从之前的demo来看,总结一下:

编译库中的代码没有直接使用的意义,也没有提供开放的api调用,最终的目的是得到编译库中生成文件,供我们调用

例如demo中,app与io-compiler是编译关系,app在运行时需要io-compiler编译生成的MainActivity$$ViewInject文件,跟io-compiler无关。

让我们来做一个比喻:

演员表

小明:扮演app。
自动售卖机:扮演编译库。
营养快线:编译库生成文件

剧情:
小明站在自动售卖机前,对它说:感觉身体被掏空,赶紧给我来瓶营养快线!然后售卖机忽忽悠悠弹出一瓶营养快线,然后小明就走了。

简单的说,就是利用编译库达成目的,目的达成就把它抛弃了,我们要的仅仅是编译库的成果。差不多就是这个意思,概念到位即可。

Provided

Provided 虽然也是编译时执行,最终不会打包到apk中,但是跟apt/annotationProcessor有着根本的不同。

一般应用场景是这样的:

A 、B、C都是Library。
A依赖了C,B也依赖了C
App需要同时使用A和B
那么其中A(或者B)可以修改与C的依赖关系为Provided

A这个Library实际上还是要用到C的,只不过它知道B那里也有一个C,自己再带一个就显得多余了,等app开始运行的时候,A就可以通过B得到C,也就是两人公用这个C。所以自己就在和B汇合之前,假设自己有C。如果运行的时候没有C,肯定就要崩溃了。

再来做一个比喻:

演员表
小明:扮演app
小刚:扮演Library(A)
小毛:扮演Library(B)

剧情:
春天到了小明寂寞难耐,给小刚和小毛打电话:今晚夜色撩人,我们去大保健吧,带上你们的会员卡,我请客!
小刚:我有XXX的会员卡,会员通用,而且不是会员不让进,十分安全,我和小毛带一张就足够了。
小毛:没问题!你带会员卡吧,我开车去接你俩。

结局1
小刚没有忘记带会员卡,一切顺利。

结局2
小刚忘记带会员卡,3个人因计划泡汤扫兴而归。

差不多就是这个意思,比喻如果有小问题不要在意,关键是意会,你懂得。

总结一下,Provided是间接的得到了依赖的Library,运行的时候必须要保证这个Library的存在,否则就会崩溃,起到了避免依赖重复资源的作用。

总结

到这里就结束了,不知道大家有没有对他们的区别有了更深的体会,如果有什么问题就留言,我们再好好的讨论。

原文链接:https://www.f2er.com/javaschema/283233.html

猜你在找的设计模式相关文章