每个页面对应自己的Component,页面Component管理着自己页面所依赖的所有类实例。
因为Component,Module,整个app的类实例结构变的很清晰。
解耦
假如不用dagger2的话,一个类的new代码是非常可能充斥在app的多个类中的,假如该类的构造函数发生变化,那这些涉及到的类都得进行修改。设计模式中提倡把容易变化的部分封装起来。
我们用了dagger2后。
假如是通过用Inject注解标注的构造函数创建类实例,则即使构造函数变的天花乱坠,我们基本上都不需要修改任何代码。
假如是通过工厂模式Module创建类实例,Module其实就是把new类实例的代码封装起来,这样即使类的构造函数发生变化,只需要修改Module即可。
有个网友问过一个这样的问题,Module的构造函数也会发生变化,发生变化后,相应的new Module的类也发生变化,这就没有达到解耦的效果。首先解耦不是说让类之间或模块之间真的一点关系都没有了,解耦达到的目的是让一个类或一个模块对与自己有关联的类或模块的影响降到最低,不是说这种影响就完全没有了,这是不可能的。
解耦还有个好处,就是方便测试,若需要替换为网络测试类,只需要修改相应的Module即可。
项目中使用dagger2注意点
具体的代码就不讲了,dagger2 sample地址,大家自行下载。这里重点说下dagger2对目标
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
类进行依赖注入的过程,现在假设要初始化目标类中的其中一个依赖类的实例,那具体步骤就在下面:
步骤1:查找Module中是否存在创建该类的方法。
步骤2:若存在创建类方法,查看该方法是否存在参数
步骤2.1:若存在参数,则按从步骤1开始依次初始化每个参数
步骤2.2:若不存在参数,则直接初始化该类实例,一次依赖注入到此结束
步骤3:若不存在创建类方法,则查找Inject注解的构造函数,
看构造函数是否存在参数
步骤3.1:若存在参数,则从步骤1开始依次初始化每个参数
步骤3.2:若不存在参数,则直接初始化该类实例,一次依赖注入到此结束
以上是dagger2进行的一次依赖注入的步骤,其实这个步骤是一个递归的过程,并且在查找类的实例的过程中Module的级别要高于Inject,这概念在上一篇讲过。
下面在说下注意的几点
- 一个app必须要有一个Component(名字可以是ApplicationComponent)用来管理app的整个全局类实例
- 多个页面可以共享一个Component
- 不是说Component就一定要对应一个或多个Module,Component也可以不包含Module
- 自定义Scope注解最好使用上,虽然不使用也是可以让项目运行起来的,但是加上好处多多。
总结
好了关于dagger2的所有的概念知识点到此终于结束了,希望能帮助大家,与大家共勉,有问题可以随时与我沟通。
作者:我是技术男
链接:https://www.jianshu.com/p/65737ac39c44