Dagger2 源码分析(三)从源码角度分析注解在 Dagger2 中的使用
Dagger2 注解
Dagger2 是基于 Java 注解来实现依赖注入的,那么在正式使用之前我们需要先了解下 Dagger2 中的注解。Dagger2 使用过程中我们通常接触到的注解主要包括:@Inject, @Module, @Provides, @Component, @Qulifier, @Scope, @Singleten。
@Inject:@Inject 有两个作用,一是用来标记需要依赖的变量,以此告诉 Dagger2 为它提供依赖;二是用来标记构造函数,Dagger2 通过 @Inject 注解可以在需要这个类实例的时候来找到这个构造函数并把相关实例构造出来,以此来为被 @Inject 标记了的变量提供依赖;
@Module:@Module 用于标注提供依赖的类。你可能会有点困惑,上面不是提到用 @Inject 标记构造函数就可以提供依赖了么,为什么还需要 @Module?很多时候我们需要提供依赖的构造函数是第三方库的,我们没法给它加上 @Inject 注解,又比如说提供以来的构造函数是带参数的,如果我们之所简单的使用 @Inject 标记它,那么他的参数又怎么来呢?@Module 正是帮我们解决这些 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 问题的。
@Provides:@Provides 用于标注 Module 所标注的类中的方法,该方法在需要提供依赖时被调用,从而把预先提供好的对象当做依赖给标注了 @Inject 的变量赋值;
@Component:@Component 用于标注接口,是依赖需求方和依赖提供方之间的桥梁。被 Component 标注的接口在编译时会生成该接口的实现类(如果 @Component 标注的接口为 CarComponent,则编译期生成的实现类为 DaggerCarComponent),我们通过调用这个实现类的方法完成注入;
@Qulifier:@Qulifier 用于自定义注解,也就是说 @Qulifier 就如同 Java 提供的几种基本元注解一样用来标记注解类。我们在使用 @Module 来标注提供依赖的方法时,方法名我们是可以随便定义的(虽然我们定义方法名一般以 provide 开头,但这并不是强制的,只是为了增加可读性而已)。那么 Dagger2 怎么知道这个方法是为谁提供依赖呢?答案就是返回值的类型,Dagger2 根据返回值的类型来决定为哪个被 @Inject 标记了的变量赋值。但是问题来了,一旦有多个一样的返回类型 Dagger2 就懵逼了。@Qulifier 的存在正式为了解决这个问题,我们使用 @Qulifier 来定义自己的注解,然后通过自定义的注解去标注提供依赖的方法和依赖需求方(也就是被 @Inject 标注的变量),这样 Dagger2 就知道为谁提供依赖了。----一个更为精简的定义:当类型不足以鉴别一个依赖的时候,我们就可以使用这个注解标示;
@Scope:@Scope 同样用于自定义注解,我能可以通过 @Scope 自定义的注解来限定注解作用域,实现局部的单例;
@Singleton:@Singleton 其实就是一个通过 @Scope 定义的注解,我们一般通过它来实现全局单例。但实际上它并不能提前全局单例,是否能提供全局单例还要取决于对应的 Component 是否为一个全局对象。
我们提到 @Inject 和 @Module 都可以提供依赖,那如果我们即在构造函数上通过标记 @Inject 提供依赖,有通过 @Module 提供依赖 Dagger2 会如何选择呢?具体规则如下:
步骤 1:首先查找 @Module 标注的类中是否存在提供依赖的方法。
步骤 2:若存在提供依赖的方法,查看该方法是否存在参数。
a:若存在参数,则按从步骤 1 开始依次初始化每个参数;
b:若不存在,则直接初始化该类实例,完成一次依赖注入。
步骤 3:若不存在提供依赖的方法,则查找 @Inject 标注的构造函数,看构造函数是否存在参数。
a:若存在参数,则从步骤 1 开始依次初始化每一个参数
b:若不存在,则直接初始化该类实例,完成一次依赖注入。
Dagger2 使用入门
1、案例 A
Car 类是需求依赖方,依赖了 Engine 类;因此我们需要在类变量 Engine 上添加 @Inject 来告诉 Dagger2 来为自己提供依赖。Engine 类是依赖提供方,因此我们需要在它的构造函数上添加 @Inject
public class Engine {
/**
二是用来标记构造函数,Dagger2 通过 @Inject 注解可以在需要这个类实例的时候来找到这个构造函数并把相关实例构造出来,
以此来为被 @Inject 标记了的变量提供依赖*/@InjectEngine(){}
@Overridepublic String toString() {return "Engine{}";}
public void run(){System.out.println("引擎转起来了~~~");}}
接下来我们需要创建一个用 @Component 标注的接口 CarComponent,这个 CarComponent 其实就是一个注入器,这里用来将 Engine 注入到 Car 中。
@Componentpublic interface CarComponent {void inject(Car car);}
完成这些之后我们需要 Build 下项目,让 Dagger2 帮我们生成相关的 Java 类。接着我们就可以在 Car 的构造函数中调用 Dagger2 生成的 DaggerCarComponent 来实现注入(这其实在前面 Car 类的代码中已经有了体现)
public class Car {/**
@Inject:@Inject 有两个作用,一是用来标记需要依赖的变量,以此告诉 Dagger2 为它提供依赖*/@InjectEngine engine;
public Car() {DaggerCarComponent.builder().build().inject(this);}
public Engine getEngine() {return this.engine;}
public static void main(String ... args){//TODO:Car car = new Car();System.out.println(car.getEngine());}}
2、案例 B
如果创建 Engine 的构造函数是带参数的呢?比如说制造一台引擎是需要齿轮(Gear)的。或者 Eggine 类是我们无法修改的呢?这时候就需要 @Module 和 @Provide 上场了。
同样我们需要在 Car 类的成员变量 Engine 上加上 @Inject 表示自己需要 Dagger2 为自己提供依赖;Engine 类的构造函数上的 @Inject 也需要去掉,应为现在不需要通过构造函数上的 @Inject 来提供依赖了。
public class Engine {
private String name;
@InjectEngine(){}
Engine(String name) {this.name = name;}
@Overridepublic String toString() {return "Engine{" +"name='" + name + ''' +'}';}
public void run() {System.out.println("引擎转起来了~~~");}}
接着我们需要一个 Module 类来生成依赖对象。前面介绍的 @Module 就是用来标准这个类的,而 @Provide 则是用来标注具体提供依赖对象的方法(这里有个不成文的规定,被 @Provide 标注的方法命名我们一般以 provide 开头,这并不是强制的但有益于提升代码的可读性)。
@Modulepublic class MarkCarModule {
public MarkCarModule(){ }
/**
用于标注 Module 所标注的类中的方法,该方法在需要提供依赖时被调用,从而把预先提供好的对象当做依赖给标注了 @Inject 的变量赋值
@return*/@ProvidesEngine provideEngine(){return new Engine("gear");}}
接下来我们还需要对 CarComponent 进行一点点修改,之前的 @Component 注解是不带参数的,现在我们需要加上 modules = {MarkCarModule.class},用来告诉 Dagger2 提供依赖的是 MarkCarModule 这个类。
@Component(modules = MarkCarModule.class)public interface CarComponent {void inject(Car car);}
Car 类的构造函数我们也需要修改,相比之前多了个 markCarModule(new MarkCarModule())方法,这就相当于告诉了注入器 DaggerCarComponent 把 MarkCarModule 提供的依赖注入到了 Car 类中。
public class Car {/**
我们提到 @Inject 和 @Module 都可以提供依赖,那如果我们即在构造函数上通过标记 @Inject 提供依赖,有通过 @Module 提供依赖 Dagger2 会如何选择呢?具体规则如下:
步骤 1:首先查找 @Module 标注的类中是否存在提供依赖的方法。
步骤 2:若存在提供依赖的方法,查看该方法是否存在参数。
a:若存在参数,则按从步骤 1 开始依次初始化每个参数;
b:若不存在,则直接初始化该类实例,完成一次依赖注入。
步骤 3:若不存在提供依赖的方法,则查找 @Inject 标注的构造函数,看构造函数是否存在参数。
a:若存在参数,则从步骤 1 开始依次初始化每一个参数
b:若不存在,则直接初始化该类实例,完成一次依赖注入*/@InjectEngine engine;
public Car() {DaggerCarComponent.builder().markCarModule(new MarkCarModule()).build().inject(this);}
public Engine getEngine() {return this.engine;}
public static void main(String ... args){//TODO:Car car = new Car();System.out.println(car.getEngine());}}
这样一个最最基本的依赖注入就完成了,接下来我们测试下我们的代码。输出
Engine{name='gear'}
3、案例 C
那么如果一台汽车有两个引擎(也就是说 Car 类中有两个 Engine 变量)怎么办呢?没关系,我们还有 @Qulifier!首先我们需要使用 Qulifier 定义两个注解:
public class Engine {
/**
用于自定义注解,也就是说 @Qulifier 就如同 Java 提供的几种基本元注解一样用来标记注解类。我们在使用 @Module 来标注提供依赖的方法时,方法名我们是可以随便定义的(虽然我们定义方法名一般以 provide 开头,但这并不是强制的,只是为了增加可读性而已)。那么 Dagger2 怎么知道这个方法是为谁提供依赖呢?答案就是返回值的类型,Dagger2 根据返回值的类型来决定为哪个被 @Inject 标记了的变量赋值。但是问题来了,一旦有多个一样的返回类型 Dagger2 就懵逼了。@Qulifier 的存在正式为了解决这个问题,我们使用 @Qulifier 来定义自己的注解,然后通过自定义的注解去标注提供依赖的方法和依赖需求方(也就是被 @Inject 标注的变量),这样 Dagger2 就知道为谁提供依赖了。----一个更为精简的定义:当类型不足以鉴别一个依赖的时候,我们就可以使用这个注解标示
使用 @Qulifier 定义两个注解*/@Qualifier@Retention(RetentionPolicy.RUNTIME)public @interface QualifierA { }@Qualifier@Retention(RetentionPolicy.RUNTIME)public @interface QualifierB { }
private String name;
Engine(String name) {this.name = name;}
@Overridepublic String toString() {return "Engine{" +"name='" + name + ''' +'}';}
public void run() {System.out.println("引擎转起来了~~~");}}
同时我们需要对依赖提供方做出修改
@Modulepublic class MarkCarModule {
public MarkCarModule(){ }
/**
同时我们需要对依赖提供方做出修改
@return*/@Engine.QualifierA@ProvidesEngine provideEngineA(){return new Engine("gearA");}
@Engine.QualifierB@ProvidesEngine provideEngineB(){return new Engine("gearB");}
评论