一、序

接:Dagger2.1不是Dagger2

demo地址:https://github.com/mrqatom/DaggerInjection

通过学习,我们知道了新版Dagger的用法,可是作为有追求的骚年,不能仅仅成为API的搬运工,必须要了解一下其中具体的用法以及实现方式。首先我们来看看几个注解的具体作用。

二、@Component.Builder

我们在AppComponent里有如下代码

    @Component.Builder
    interface Builder {
        @BindsInstance
        Builder application(Application application);

        AppComponent build();
    }

我们大概也猜出他的作用,就是自定义构造component

以前我们的用法像这样:

 @Module
 public class AppModule {
 
    Application application;
 
    public AppModule(Application application) {
       this.application = application;
    }
 
    @Provides
    Application providesApplication() {
       return application;
    }
    @Provides
    public SharedPreferences providePreferences() {
        return application.getSharedPreferences(DATA_STORE,
                              Context.MODE_PRIVATE);
    }
 
 }


//使用时
DaggerAppComponent appComponent = DaggerAppComponent.builder()
         .appModule(new AppModule(this)) //this : application 
         .build();

现在Dagger允许我们自定义Builder:

@Component(modules = {AppModule.class})
public interface AppComponent {
   
   void inject(MainActivity mainActivity);

   @Component.Builder
   interface Builder {
        AppComponent build();
        Builder appModule(AppModule appModule);
    }
}

就像我们以前的用法一样。这看起来多此一举,不过,配合@BindsInstance就会发生不一样的化学反应,下面我们来看看:

@Module
 public class AppModule {
 
     @Provides
     @Singleton
     public SharedPreferences providePreferences(
                                    Application application) {
         return application.getSharedPreferences(
                                    "store", Context.MODE_PRIVATE);
     }
 }


@Component(modules = {AppModule.class})
public interface AppComponent {
   void inject(MainActivity mainActivity);
   SharedPreferences getSharedPrefs();
   @Component.Builder
   interface Builder {
   
      AppComponent build();
      @BindsInstance Builder application(Application application);      
  }


//使用时
DaggerAppComponent appComponent = DaggerAppComponent.builder()
           .application(this)
           .build();

我们的代码发生了如下改变:

1、AppModule不再需要Application为参数的构造函数,可以直接使用Application

2、component里加入application并加上了@BindsInstance注解,而且无需传入Module

3、使用时无需传入Module而仅仅需要application即可

这个注解有效的简化了Module的初始化并减少了与module的耦合,所以再回头看看demo里的AppComponent是不是更清晰了些呢?

三、@IntoMap

这个注解看名字就可以猜测,用来把什么东西加入map里。

是的,就是把依赖加入map里,先来看看官方简单的例子:

@Module
class MyModule {
  @Provides @IntoMap
  @StringKey("foo")
  static Long provideFooValue() {
    return 100L;
  }

  @Provides @IntoMap
  @ClassKey(Thing.class)
  static String provideThingValue() {
    return "value for Thing";
  }
}

@Component(modules = MyModule.class)
interface MyComponent {
  Map<String, Long> longsByString();
  Map<Class<?>, String> stringsByClass();
}

@Test void testMyComponent() {
  MyComponent myComponent = DaggerMyComponent.create();
  assertThat(myComponent.longsByString().get("foo")).isEqualTo(100L);
  assertThat(myComponent.stringsByClass().get(Thing.class))
      .isEqualTo("value for Thing");
}

我们来梳理一下重点:

1、@intoMap需要和@provides及@binds之类的注解配合使用,这很好理解,就是把依赖in to map而已

2、需要和@mapKey配合使用,即map的key,比如StringKey、ClassKey、ActivityKey…balabala…

3、使用时就和普通map一样

四、@Binds

@Binds和@provides一样,都是提供依赖的作用,也可以说是优化版,我们先来看看@provides的用法:

@Provides
public LoginContract.Presenter 
  provideLoginPresenter(LoginPresenter loginPresenter) {
    return loginPresenter;
}

这应该是Dagger使用者比较常见的格式了,相比之下@Binds方式就显得更简洁了:

@Binds
public abstract LoginContract.Presenter
  provideLoginPresenter(LoginPresenter loginPresenter);

以下是重点:

1、binds方式是抽象方法,无需方法体

2、只能有一个参数且return类型与其相同

3、使用@Binds后该module变为抽象(废话

4、@binds与@provides不得在同一个Module中使用,必须分开写在两个Module里,可以使用include使其关联就像这样

@Module(includes = Declarations.class)
public class MainActivityModule {
    @Provides
    MainPresenter provideMainPresenter(MainView mainView, ApiService apiService) {
        return new MainPresenter(mainView, apiService);
    }
}

@Module
public abstract class Declarations {
    @Binds
    abstract MainView provideMainView(MainActivity mainActivity);
}

5、如果你一定要将他们写在一个module里,也有方案,把@provides方法变为static即可:

@Module
public abstract class MainActivityModule {
    @Binds
    abstract MainView provideMainView(MainActivity mainActivity);

    @Provides
    static MainPresenter provideMainPresenter(MainView mainView, ApiService apiService) {
        return new MainPresenter(mainView, apiService);
    }
}

五、源码解析

Dagger2是利用APT自动化形成,这里我就不详述了不然一篇文章根本不够,大家可以自行谷歌关键字:‘APT’、‘编译期注解’

我不会一段一段代码的贴,而是讲述大概流程以及一些思想,避免“休闲式学习”,所以大家需要自己打开源码浏览,如果仅看文章大概率会懵逼:),先来看一段Dagger的初始代码

public class MyApplication extends Application implements HasActivityInjector {
    @Inject
    DispatchingAndroidInjector<Activity> dispatchingAndroidInjector;

    @Override
    public void onCreate() {
        super.onCreate();
        DaggerAppComponent.builder().application(this).build().inject(this);
    }

    @Override
    public AndroidInjector<Activity> activityInjector() {
        return dispatchingAndroidInjector;
    }
}

继承HasActivityInjector重写activityInjector,定义DispatchingAndroidInjector加上@Inject这里先提一下,后面有用。

主要是 DaggerAppComponent.builder().application(this).build().inject(this) 这句代码,这是一句很明显的建造者模式的代码,是由我们自定义的@Component.Builder形成的,当我们调用.build时会对DaggerAppComponent进行初始化即调用initialize方法,代码如下:

  private void initialize(final Builder builder) {
    this.mainActivityComponentBuilderProvider =
        new Provider<MainActivityComponent.Builder>() {
          @Override
          public MainActivityComponent.Builder get() {
            return new MainActivityComponentBuilder();
          }
        };
  }

初始化时创建了ActivityBuilder中由@Binds注解的方法return的类,并用Provider封装了一层,其实也就是我们的@Subcomponent.Builder修饰的类而已,这里我们仅有一个MainActivity

这个类实际上只是一个创建者,调用build方法创建真正的实现类:MainActivityComponentImpl,在这个类里会提供我们Module里用provides注解的依赖,我们对比一下:

    //Module中
    @Provides
    MainView provideMainView(MainActivity mainActivity){
        return mainActivity;
    }
    @Provides
    MainPresenter provideMainPresenter(MainView mainView, ApiService apiService) {
        return new MainPresenter(mainView, apiService);
    }



    //源码中
    private MainView getMainView() {
      return MainActivityModule_ProvideMainViewFactory.proxyProvideMainView(
          mainActivityModule, seedInstance);
    }

    private MainPresenter getMainPresenter() {
      return MainActivityModule_ProvideMainPresenterFactory.proxyProvideMainPresenter(
          mainActivityModule, getMainView(), new ApiService());
    }

proxyProvideMainPresenter其实就是调用module的provideMainPresenter来生成一个Mainpresenter

当MainActivityComponentImpl的inject方法被调用时,以上方法也同时被调用,像这样:

    @Override
    public void inject(MainActivity arg0) {
      injectMainActivity(arg0);
    }

    private MainActivity injectMainActivity(MainActivity instance) {
      //....省略
      MainActivity_MembersInjector.injectPresenter(instance, getMainPresenter());
      return instance;
    }

MainActivity_MembersInjector.injectPresenter会将生成的Mainpresenter注入到MainActivity里,也就完成了依赖注入。

至于inject方法什么时候被调用,以及MainActivity如何传入的留待后文分析,我们先回到初始化的地方。

DaggerAppComponent构建完成之后,又调用了他的Inject方法,这个方法了只做了一件事,就是初始化MyApplication中的

DispatchingAndroidInjector,而他里面就保存了我们上面提到的MainActivityComponentBuilder,如果有多个Activity的话,就会把他们保存到一个map中,key为activity名字,这就是@IntoMap的作用了。

所以DispatchingAndroidInjector其实提供了一个仓库的作用,仓库里保存了我们在ActivityBuilder里@binds修饰的类,其实也就是我们所有的Activity

还记得我们在MyApplication中重写的方法吗?

@Override
    public AndroidInjector<Activity> activityInjector() {
        return dispatchingAndroidInjector;
    }

通过这个方法就可以获取到该“仓库”,然后一步步获取到真正的实现类完成依赖注入,具体我们继续看。

那我们Activity如何获取到该’仓库‘呢?在每一个Activity中都需要调用一句代码:

  AndroidInjection.inject(this);



  //实现
  public static void inject(Activity activity) {
    checkNotNull(activity, "activity");
    //拿到application
    Application application = activity.getApplication();
    //判断application是否继承了HasActivityInjector
    if (!(application instanceof HasActivityInjector)) {
      throw new RuntimeException(
          String.format(
              "%s does not implement %s",
              application.getClass().getCanonicalName(),
              HasActivityInjector.class.getCanonicalName()));
    }
    //通过刚刚讲到的方法拿到“仓库”
    AndroidInjector<Activity> activityInjector =
        ((HasActivityInjector) application).activityInjector();
    checkNotNull(activityInjector, "%s.activityInjector() returned null", application.getClass());
    //调用“仓库”的inject方法,并传入了相应的Activity
    activityInjector.inject(activity);
  }

“仓库”的inject方法会在map里找到我们之前所说的真正实现类完成所有依赖注入工作。

因为“仓库”保存了我们所有Activity,所以只要在Activity里调用上述代码就能完成该Activity的依赖注入。

至于Fragment的注入是如何实现由读者自行阅读,就是在Activity依赖注入实现类里又创建了一个Fragment的ComponentBuilder而已,类似于递归的思想。

至于@ContributesAndroidInjector的实现方式就是和基本版相同,只是自动生成了component而已,帮我们简化了操作。

总结

看完大家可能觉得Dagger源码解析部分很少,事实上Dagger的源码确实不算难,适合刚刚学习看源码的童鞋,克服源码的恐惧就是现在了。至于编译期注解方面的知识,建议大家去看Arouter源码上手。

Dagger的思想是非常优秀的,加上现在更新的越来越简洁,非常推荐大家尝试使用。

作者:verymrq 发表于 2018/08/30 10:38:35 原文链接 https://ift.tt/2wsiO18
阅读:0

from verymrq的博客 https://ift.tt/2wsiO18
via IFTTT

Categories: Android

4 Comments

Pang · 2019年1月1日 at 上午12:57

将就在这个页面吧。

新年快乐~

    veryatom · 2019年3月4日 at 上午11:18

    好久没来了~

asd · 2019年5月31日 at 上午11:42

asasd

asd · 2019年5月31日 at 上午11:45

测试评论

发表评论

电子邮件地址不会被公开。