Android-Rxjava&retrofit&daggerAndroidAndroid-Dagger2

Android Dagger2 从零单排(一) 基础注解

2018-05-08  本文已影响1472人  MrTangFB

  转发请注明出处:https://www.jianshu.com/p/7ee1a1100fab
  Dagger2作为Android界最具杀伤力的匕首,本系列文章将用最通俗的语言带领你揭开它的真面目。
  边缘OB:从零单排带你从低分局打到高分局,从First Blood(第一滴血)到Holy Shit(超越神的杀戮),每盘Rampage(暴走)不在话下!
  Android Dagger2 从零单排(一) 基础注解
  Android Dagger2 从零单排(二) @Qualifier
  Android Dagger2 从零单排(三) @Scope
  Android Dagger2 从零单排(四) Dependencies与SubComponent

1.Dagger2简介

  "A fast dependency injector for Android and Java."
  Dagger2GitHub地址的首页简介就这么一句话,Android和java的快速依赖注入。简单述说就是组件只管依赖的使用,而依赖的具体实现交给容器去决定,这是DI(Dependency Injection)框架的核心思想。另外使用Dagger2不用担心性能的消耗,不使用反射,所有的注解均停留在编译时期。

2.配置Dagger2:

dependencies {
    api 'com.google.dagger:dagger:2.x'
    annotationProcessor 'com.google.dagger:dagger-compiler:2.x'
}

  注意:如果gradle版本低于2.2,需要使用apt插件,Kotlin写法也有点。

3.注解的分类:

  在描述注解的作用前,我们先看dagger2最简单的例子,
  例子一,假设领导下午要出去视察民情,需要一辆公交车,司机就不用请了,领导做表率自己开,小秘把领导的指示告诉了车场调度员。
  找辆公交车要停放在停车场(Bus要注入到ParkingActivity),停车场不管公交车按什么路线停车(ParkingActivity不管Bus是如何注入的),车场调度员会负责好管理(Dagger2容器会将Bus的注入到ParkingActivity)。
  DaggerParkingComponent类是编译过后Dagger2自动生成的,是ParkingComponent的实现类,可以说DaggerParkingComponent就是实际的车场调度员,ParkingComponent是对车场调度员的约束,在onCreate方法完成了注入过程。

public class Bus {
    @Inject
    public Bus() {
    }
}

public class ParkingActivity extends Activity {
    @Inject
    Bus mBus;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_dagger);
        DaggerParkingComponent.create().inject(this);//DaggerParkingComponent类需要编译才会生成
        ((TextView) findViewById(R.id.text)).setText(mBus.toString());
    }
}

@Component
public interface ParkingComponent {
    void inject(ParkingActivity activity);
}

@Inject注解:
  (1)注解在属性中表示该属性需要依赖注入,不能使用private修饰,示例代码表示需要注入属性mBus(Bus的车位):

    @Inject
    Bus mBus;

  (2)注解在方法中表示该方法需要依赖注入,不能是抽象方法,不能使用private修饰,示例代码表示需要注入方法injectBus:

    //@Inject
    Bus mBus;
    @Inject
    public void injectBus(Bus bus) {
        mBus = bus;
    }

  方法注入的参数同样由Dagger2容器提供,以上代码的目的与第一点介绍的属性注入一样,都是为了注入mBus,如果目的是注入属性的话,方法注入和属性注入基本没有区别,属性注入是Dagger2中使用最多的一个注入方式。
  那么什么情况下应该使用方法注入?比如依赖需要this对象的时候,方法注入可以提供安全的this对象。
  注意,Dagger2容器先调用属性注入,然后再方法注入,若把示例代码mBus的@Inject取消注释,此时mBus会注入2次,并且两次注入的Bus也不相同。
  (3)注解在构造方法中表示此类能为Dagger2提供依赖关系,Dagger2可以使用这个构造方法构建对象(Bus的来历):

    @Inject
    public Bus() {
    }

  如果有多个构造函数,只能注解一个,否则编译报错,多构造方法的方式下一篇会介绍。
@Component注解:
  一般用来注解接口,被注解的接口在编译时会生成相应的实例,实例名称一般以Dagger为前缀,作为所需注入依赖(ParkingActivity的mBus属性)和提供依赖(Bus类构造方法)之间的桥梁,把提供的依赖(Bus)注入到所需注入的依赖中(ParkingActivity的mBus属性)。
  通俗说,就是Dagger2的容器,在例子中是车场调度员,把公交车和停车场联系在一起。车场调度员知道停车场要准备一辆公交车,停车场不需要知道车是哪里来的,也不需要知道怎么停,车场调度员找好车后,停在车位上就完事,等候领导用车就可以了。
  例子一总结,两个@Inject注解形成了依赖关系,@Component作为连接这个关系的桥梁存在,寻找到依赖并且注入,并且注入与被注入之间互不干涉,经过编译@Component生成Dagger为前缀的实例,调用实例的方法注入。

  例子二,领导想着不妥,自己没开过公交车,为保险起见还是赶紧吩咐小秘,去给配个公交车司机,小秘自然跟车场调度员说了。
  车场调度员一想,只是比之前多了一个步骤,给公交车配置一个司机(Bus类添加String类型Driver构造方法)。于是打电话给开公交车的隔壁老王,老王自然是应诺了下来,于是乎,对例子一的代码做一下修改。

public class Bus {
    private String driver;
    @Inject
    public Bus(String driver) {
        this.driver = driver;
    }
}

public class ParkingActivity extends Activity {
    @Inject
    Bus mBus;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_dagger);
        DaggerParkingComponent.create().inject(this);//DaggerParkingComponent类需要编译才会生成
        ((TextView) findViewById(R.id.text)).setText(mBus.toString());//重写Bus的toString()方法能看到打印出"隔壁老王",注入成功
    }
}

@Component(modules = ParkingModule.class)
public interface ParkingComponent {
    void inject(ParkingActivity activity);
}

@Module
public class ParkingModule {
    public ParkingModule() {
    }
    @Provides
    public String provideDriver() {
        return "隔壁老王";
    }
}

@Module注解:
  该注解与@Provides结合为Dagger2提供依赖关系,对上文@Inject第三点的补充,用于不能用@Inject提供依赖的地方,如第三方库提供的类,基本数据类型等不能修改源码的情况。
@Provides注解:
  @Provides仅能注解方法,且方法所在类要有@Module注解。注解后的方法表示Dagger2能用该方法实例对象提供依赖。按照惯例,@Provides方法的命名以provide为前缀,方便阅读管理。
  例子二总结,首先@Component注解包含了一个ParkingModule类,表示Dagger2可以从ParkingModule类查找依赖,Dagger2会自动查找ParkingModule类有@Provides注释的方法实例依赖,最后完成注入
  注意1,如果在ParkingModule里面同样提供Bus的依赖,Dagger2会优先在@Module注解的类上查找依赖,没有的情况才会去查询类的@Inject构造方法,如下面的代码,则Bus的司机就是小王而不是老王了。

@Module
public class ParkingModule {
    public ParkingModule() {
    }
    @Provides
    public String provideDriver() {
        return "隔壁老王";
    }
    @Provides
    public Bus provideBus() {
        return new Bus("楼上小王");
    }
}

  注意2,@Module类可以从构造方法传入依赖,@Provides方法也可以有依赖关系。
  @Provides方法也有依赖关系的情况,Dagger2会继续查找可以提供依赖的方法,类似于一种递归的状态,一步一步返回实例。如下代码,ParkingModule构造方法传入driver为provideDriver方法提供依赖返回,provideDriver返回driver作为provideBus方法的依赖实例Bus。
  ParkingModule加入有参构造方法后,调用方式也需要变成,现在司机就变成了楼下老李了。

@Module
public class ParkingModule {
    private String driver;
    public ParkingModule(String driver) {
        this.driver = driver;
    }
    @Provides
    public String provideDriver() {
        return driver;
    }
    @Provides
    public Bus provideBus(String driver) {
        return new Bus(driver);
    }
}
    //调用方式改变
    DaggerParkingComponent.builder().parkingModule(new ParkingModule("楼下老李")).build().inject(this);

关于注入方法的疑惑:
  初次接触Dagger2时,会发现每次Build之后,create()方法时有时无,其实create()方法是简化注入流程而设计的,点进去看源码实际上是在内部帮你调用了。

  public static MainComponent create() {
    return new Builder().build();
  }

以下情况都会生成create()方法:
  (1)@Component注解接口没有声明任何Module,这种情况自然不必多说。
  (2)@Component注解接口声明了Module,没有使用Module提供的依赖,无论Module构造方法是否有参,这种情况@Component注解生成的Java文件也有提示:

    /**大约意思就是你声明了Module,但component没有用到里面的实例,实例Module是多余无用的操作。
     * @deprecated This module is declared, but an instance is not used in the component. This
     *     method is a no-op. For more, see https://google.github.io/dagger/unused-modules.
     */

  (3)@Component注解接口声明了Module,使用了Module提供的依赖,Module构造方法没有参数,点进去看源码实际上是在内部初始化了Module。

    public MainComponent build() {
      if (mainModule == null) {
        this.mainModule = new MainModule();
      }
      return new DaggerMainComponent(this);
    }

下面这种是一定不会有create()方法出现:
  (1)@Component注解接口声明了Module,使用了Module提供的依赖,Module构造方法有参数,无论你是否使用了该参数作为依赖,这时候注入都需要初始化Module才能注入成功,看源码如果不初始化Module会直接报异常。

    public MainComponent build() {
      if (mainModule == null) {
        throw new IllegalStateException(MainModule.class.getCanonicalName() + " must be set");
      }
      return new DaggerMainComponent(this);
    }

  开始接触时create()方法可以作为检测手段,例如声明了Module,且Module构造方法有参数,如果有create()方法,表明此时没使用Module提供的依赖,可以在Module查找下原因。实际项目运用中,create()方法比较少使用,一般Module都会传参。

最后总结了一下依赖注入流程:
1:查找Module中是否有该实例的@Provides方法。
  1.1:有,走第2点。
  1.2:没有,查找该实例是否有@Inject构造方法。
    1.1.1:有,走第3点。
    1.1.2:没有,注入失败。
2:@Provides方法是否有参数
  2.1:有,则回到第1点查找每个参数的依赖
  2.2:没有,实例该类返回一次依赖
3:@Inject构造方法是否有参数
  3.1:有,则回到第1点查找每个参数的依赖
  3.2:没有,实例该类返回一次依赖
4:以上流程递归返回注入目标的所有依赖,最后依赖注入。

  Demo源码截我 对应daggerOne包名
  Dagger2 GitHub地址
  Dagger2 官网地址
  所有的测试实例均基于2.15版本。
  下一篇,我们来研究多构造方法与多个@Provides方法返回同一数据类型的情况:@Qualifier注解。

上一篇下一篇

猜你喜欢

热点阅读