强行来一波Dagger2使用介绍

安卓基础开发库,让开发简单点。
DevRing & Demo地址github.com/LJYcoder/De…

学习/参考地址:
https://www.jianshu.com/p/cd2c1c9f68d4
https://blog.csdn.net/lisdye2/article/details/51942511
https://www.jianshu.com/p/24af4c102f62

前言

Dagger2已经出来挺久了,网上相关的教程也很多,但我还是坚持要写这篇,做事要有始有终嘛(这应该是本系列介绍的最后一个框架了,也是本系列最难上手的一个框架)
由于接触Dagger2的时间不长,有些理解可能也不到位,但我还是会尽我所能把它讲清楚些,不当之处也请大家指出。

什么是Dagger2

Dagger2是一个依赖注入(Dependency Injection)框架。

什么又是依赖注入呢?

借别人的话来说,就是“目标类中所依赖的其他类的初始化过程,不是通过在目标类中编码的方式完成,而是通过其他手段把已经初始化好的实例自动注入到目标类中”。

再换种方式来说,就是把类实例的初始化过程都挪至一个地方统一管理,具体需要哪个实例时,就从这个地方取出(注入到目标类中)。

使用Dagger2有什么好处

知其然,然后要知其所以然。

1. 解耦

假设有一个A类,项目中很多地方都使用到它(在很多地方通过new A()对A实例进行了初始化)。然后由于需求变动,A的构造函数增加了一个参数。
好了,牵一发而动全身,你需要把各个new A()的地方都进行修改。
但如果是使用Dagger2进行管理,你只需在类实例的供应端进行修改即可。

2. 让功能实现更专注于功能实现

假设现在你需要调用A类的x()方法来实现某功能,但是A类的构造过程相当的复杂(这样的例子可以参考GreenDao中获取XXXDao、Retrofit中获取Observable请求)

public void xxx(){
    E e = new E();
    D d = new D(e);
    C c = new C();
    B b = new B(c,d);
    A a = new A(b);
    a.x();
}
复制代码

结果6行代码中,构造实例a占了5行,调用x()方法实现功能却只占了1行。
但如果使用Dagger2进行管理,将a实例的构造过程移至实例供应端,则功能实现模块的代码会变成这样

@Injcet
A a;
public void xxx(){
    a.x();
}
复制代码

这就是所说的让功能实现更专注于功能实现,而不必去管a实例的构造过程。

3. 更好地管理类实例

通常我们开发中会有两种类实例:
一种是全局实例(单例),它们的生命周期与app保持一致。
一种是页面实例,它们的生命周期与页面保持一致。
通过Dagger2,我们可以使用一个组件专门管理全局类实例(也免去了单例的写法,不用考虑饿汉懒汉什么的);然后各个页面也有各自组件去管理它们的页面实例。
这样不管是对于实例的管理,还是项目的结构,都会变得更加的清晰明了。

4. 逼格高

(这点可以略过...)
当你不认识Dagger2却看着使用Dagger2的项目代码,很可能会感觉到一种茫然与高大上:
各种@Inject,@Provides,@Singleton,Lazy<>,Provider<>等是什么鬼?
为什么没有实例化的代码?
为什么明明是null却不会报空指针?
等你学会使用Dagger2之后,你也可以来一波"高逼格"的代码。

当然,这里也不得不提一下,使用Dagger2会增加代码量。所以如果是小项目/独立开发,你也可以考虑不用,因为你可能有种失大于得的感觉。如果是大项目/团队开发,使用后就得大于失了。


角色介绍

在讲用法前,先对几个重要角色进行了解。

实例需求端

一个类中,它包含了实例成员,在使用这些实例前,需要对它们进行初始化,但前面已经说了初始化的过程挪至其他地方。所以这个类的需求是,已经完成初始化的实例对象。 暂且把这样的类称为“实例需求端”。

实例供应端

进行实例初始化的地方,并对外供应所需的实例。

Dagger2中,供应端有两种方式可以供应实例:(后面会介绍) 第一种:使用Module 第二种:使用@Inject标注构造函数

桥梁

实例供应端并不知道它要供应的实例交给谁。 这个时候就需要通过桥梁,将实例需求端与实例供应端联系在一起。

Dagger2中,Component就负责扮演桥梁的角色。

使用介绍

1. 初步使用

1.1 添加依赖

compile 'com.google.dagger:dagger:2.14.1'
annotationProcessor 'com.google.dagger:dagger-compiler:2.14.1'
复制代码

1.2 处理实例需求端

在实例需求端中,使用@Inject标注需要注入的实例变量。

public class UploadActivity extends AppCompatActivity{
    @Inject
    UploadPresenter mPresenter;
}
复制代码

1.3 处理实例供应端

前面说了,供应端有两种方式可以供应实例。

方式一 使用Module
  • 使用@Module标注类,表示它为供应端
  • 在类中使用@Provides标注方法,表示它为提供实例的方法。 在该方法中对实例进行初始化并返回该实例。
@Module
public class UploadActivityModule {
    @Provides
    UploadPresenter uploadPresenter() {
        return new UploadPresenter();
    }
}
复制代码
方式二 使用@Inject标注构造函数
public class UploadPresenter{
    @Inject
    public UploadPresenter() {
    }
}
复制代码
注意

方式一的优先级高于方式二,意思就是:

  • 在供应某实例时,会先通过方式一查找是否存在返回该实例的的方法
  • 如果存在,则获取实例并对外供应
  • 如果不存在,再通过方式二查找是否存在@Inject标注的构造函数
  • 如果存在,则将通过该构造函数构造实例并对外供应
  • 如果不存在,那将报错,因为无法供应所需的实例

1.4 搭建桥梁

  • 使用@Component标注接口,表示它为桥梁。
    (如果使用1.3.1的方式供应实例,则需在@Component(modules=xxx.class)中指明module。)
    一个Component可以没有module,也可以同时有多个module。
  • 添加 void inject(实例需求端) 方法,表明实例供应端中的实例将交给该实例需求端。
    通过这个方法,查找实例需求端中需要注入的实例有哪些(使用@Inject标注的那些实例),然后在实例供应端中获取所需的实例,最后注入到实例需求端中
  • 用来注入的方法,它的方法名不一定要是inject,可以随便取,一般都取inject。但该方法的返回类型必须为void
@Component(modules = UploadActivityModule.class)
public interface UploadActivityComponent {
    void inject(UploadActivity uploadActivity);
}
复制代码

1.5 编译,注入

  • 完成以上几步后,ReBuild一下项目以生成DaggerUploadActivityComponent类。
  • 在实例需求端中调用inject完成实例的注入
public class UploadActivity extends AppCompatActivity{
    @Inject
    UploadPresenter mPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerUploadActivityComponent.builder()
            .build()
            .inject(this);

        //注入后即可调用mPresenter中的方法了
        mPresenter.xxx();
    }
}
复制代码

2. 接收外部参数

有些时候,实例的初始化需要接收外部参数才能完成,比如MVP中的Presenter往往需要传入IView接口以便完成数据回调。

现在UploadPresenter的构造函数发生了变动,需传入IUploadView。

public class UploadPresenter{
    IUploadView mIView;
    public UploadPresenter(IUploadView iview) {
          mIView = iview;
    }
}
复制代码

下面介绍两种方式来接收外部参数

2.1 方式一 通过Module的构造函数传入

对实例供应端的module进行改造
@Module
public class UploadActivityModule {
    IUploadView mIView;
    public UploadActivityModule(IUploadView iview) {
        mIView = iview;
    }

    @Provides
    IUploadView iUploadView(){
         return mIView;
    }

    @Provides
    UploadPresenter uploadPresenter(IUploadView iview) {
        return new UploadPresenter(iview);
    }
}
复制代码
  • 添加了构造函数以便获取外部参数IUploadView
  • uploadPresenter()方法添加了IUploadView参数
    • 到时构建UploadPresenter实例时,会在这个Module或者同个Component下的其他Module中查找是否存在返回IUploadView的的方法
    • 如果存在,则通过该方法获取IUploadView以构造UploadPresenter
    • 如果不存在,则通过1.3.2方式查找是否存在@Inject标注的构造函数(当然不会存在,因为IUploadView是接口)
  • 不直接使用mIView来构造UploadPresenter是为了降低耦合度。uploadPresenter()方法只管获取构造Presenter所需的参数,而该参数从哪来、以后会有哪些变动,交给iUploadView()方法处理即可。

利用Module构造函数传入外部参数

public class UploadActivity implements IUploadView{
    @Inject
    UploadPresenter mPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerUploadActivityComponent.builder()
            .uploadActivityModule(new UploadActivityModule(this))//通过构造函数传入外部参数IUploadView
            .build()
            .inject(this);

        //注入后即可调用mPresenter中的方法了
        mPresenter.xxx();
    }

    //实现IUploadView接口的方法
    @Override
    public void onUploadSuccess() {
        //上传成功
    }
    @Override
    public void onUploadFail() {
        //上传失败
    }
}
复制代码

2.2 方式二 通过Component传入

对桥梁Component进行改造
@Component(modules = UploadActivityModule.class)
public interface UploadActivityComponent {
    void inject(UploadActivity uploadActivity);

    IUploadView iUploadView();

    @Component.Builder
    interface Builder {
        @BindsInstance
        Builder iUploadView(IUploadView iUploadView);

        UploadActivityComponent build();
    }
}
复制代码
  • 加入iUploadView()方法返回IUploadView
  • 加入了Builder来接收IUploadView
构建Component时传入外部参数
public class UploadActivity extends AppCompatActivity implements IUploadView{
    @Inject
    UploadPresenter mPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerUploadActivityComponent.builder()
            .iUploadView(this)
            .build()
            .inject(this);

        //注入后即可调用mPresenter中的方法了
        mPresenter.xxx();
    }

    //实现IUploadView接口的方法
    @Override
    public void onUploadSuccess() {
        //上传成功
    }
    @Override
    public void onUploadFail() {
        //上传失败
    }
}
复制代码

3. 限定符注解 @Qualifier

@Qualifier主要是用于解决,因供应端存在多个类型相同的实例而引起歧义的问题。

3.1 使用@Named注解

Dagger2默认提供了一个@Named注解,从代码可以看出属于@Qualifier的一种实现。

@Qualifier
@Documented
@Retention(RUNTIME)
public @interface Named {
    String value() default "";
}
复制代码

下面举个例子,现在页面需有两个Dialog,一个用于登录,一个用于注册。

@Module
public class TestActivityModule {
    private Context mContext;

    public TestActivityModule(Context context){
          mContext = context;
    }

    @Provides
    Context context(){
          return mContext;
    }
    
    @Named("login")
    @Provides
    Dialog loginDialog(Context context){
         Dialog dialog = new Dialog(context);
         dialog.setTitle("登录提示");
         ....
         return dialog;
    }

    @Named("register")
    @Provides
    Dialog registerDialog(Context context){
         Dialog dialog = new Dialog(context);
         dialog.setTitle("注册提示");
         ....
         return dialog;
    }
}
复制代码
  • 可以看到,在实例供应端中,需在提供Dialog实例的方法上面加@Named注解以区分。如果不加则会报错,因为Dagger2不知道要使用哪个方法来获取Dialog实例。
@Component(modules = TestActivityModule.class)
public interface TestActivityComponent {
    void inject(TestActivity testActivity);
}
复制代码
public class TestActivity extends AppCompatActivity{
    @Named("login")
    @Inject
    Dialog mDialogLogin;
    
    @Named("register")
    @Inject
    Dialog mDialogRegister;      

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerTestActivityComponent.builder()
            .testActivityModule(new TestActivityModule(this))
            .build()
            .inject(this);
    }    
}
复制代码
  • 在实例需求端中,同样要使用@Named注解标注要注入的实例。让Dagger2知道,
    @Named("login")标注的mDialogLogin,需要通过@Named("login")标注的供应方法来获取。
    @Named("register")标注的mDialogRegister,需要通过@Named("register")标注的供应方法来获取。

3.2 自定义@Qualifier注解

使用@Named注解的话,需要加入字符串来区分,这样比较麻烦也容易出错。所以我们可以使用自定义的限定符注解。

@Qualifier
public @interface DialogLogin {
}
复制代码
@Qualifier
public @interface DialogRegister {
}
复制代码

然后把前面涉及的@Named("login")换成@DialogLogin,@Named("register")换成@DialogRegister即可~


4. 作用域注解 @Scope

@Scope的作用是使同一个Component中供应的实例保持唯一。

4.1 使用作用域注解实现局部单例

举例说明:

public class UploadActivity extends AppCompatActivity{
    @Inject
    UploadPresenter mPresenter1;
    @Inject
    UploadPresenter mPresenter2;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerUploadActivityComponent.builder()
            .build()
            .inject(this);
    }
}
复制代码
  • 如果不使用作用域注解,则代码中的mPresenter1,mPresenter2将会是两个不一样的实例,可通过打印内存地址查看。
  • 而如下使用作用域注解后,则两者将会是同一个实例,可通过打印内存地址查看。
步骤1 自定义@Scope注解
@Scope
@Documented
@Retention(RUNTIME)
public @interface ActivityScope {}
复制代码
步骤2 桥梁Component添加作用域注解
@ActivityScope 
@Component(modules = UploadActivityModule.class)
public interface UploadActivityComponent {
    void inject(UploadActivity uploadActivity);
}
复制代码
步骤3 供应端中提供实例的方法添加作用域注解
@Module
public class UploadActivityModule {
    @ActivityScope
    @Provides
    UploadPresenter uploadPresenter() {
        return new UploadPresenter();
    }
}
复制代码

如果是使用1.3.2方式提供实例,则在类上方添加作用域注解

@ActivityScope
public class UploadPresenter{
    @Inject
    public UploadPresenter() {
    }
}
复制代码

经过@Scope处理后,UploadActivity中的UploadPresenter实例将保持唯一。

4.2 使用作用域注解实现全局单例

全局单例,相信大家就很熟悉了,就是平时用饿汉懒汉等等写的那种单例模式。
前面已经说过@Scope作用是使同一个Component中供应的实例保持唯一。
也就是说,如果我在另一个Activity中再创建了一个新的Component,那么它所提供的UploadPresenter实例也将是新的。
这和我们理解的全局单例并不一样。
所以,要想实现全局单例,那就要确保获取实例的Component一直都是同一个。
如何实现呢?答案是创建一个Component用于提供全局单例的实例,然后在Application中对该Component进行初始化,以后要获取单例时,都统一通过它来获取。

全局性的实例供应端

@Module
public class AppModule {
    private Application mApplication;

    public AppModule (Application application){
          mApplication = application;
    }

    @Singleton
    @Provides
    Application application(){
          return mApplication;
    }

    @Singleton
    @Provides
    ActivityStackManager activityStackManager() {
        return new ActivityStackManager();
    }
}
复制代码

全局性的桥梁

@Singleton
@Component(modules = AppModule.class)
public interface AppComponent {
    ActivityStackManager activityStackManager();
    Application application();
}
复制代码

Application中初始化

public class MyApplication extends Application {

    public static AppComponent mAppComponent;

    @Override
    public void onCreate() {
        super.onCreate();
       
        mAppComponent= DaggerAppComponent.builder()
              .appModule(new AppModule(this))
              .build();
    }
}
复制代码

每次都通过Application中的AppComponent获取某实例,即可保证全局单例

public class UploadActivity extends AppCompatActivity{

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
   
        MyApplication.mAppComponent.activityStackManager().pushOneActivity(this);     
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();

        MyApplication.mAppComponent.activityStackManager().popOneActivity(this);   
    }
}
复制代码
  • 使用了Dagger2默认提供的作用域注解@Singleton,通过源码可以发现它的实现其实和前面的@ActivityScope是一样的。
  • 所以真正实现全局单例的不是并@Singleton,而是使用每次获取实例都通过同一个Component。
  • 但由于它的字面意思为单例,所以我们通常把它应用在全局性的桥梁和实例供应端中。
  • 全局性的Component中没有加入inject方法来自动注入(当然你也可以这么做,但全局性的比较少这么做),而是加入了activityStackManager()方法,供外部调用来获取实例。

5. Lazy 和 Provider

假如你并不希望在调用inject()方法后,就对@Inject标注的实例进行初始化注入,而是希望在用到该实例的时候再进行初始化,那么我们就可以使用Lazy和Provider来实现。

举例说明(省略实例供应端和桥梁的代码)

public class UploadActivity extends AppCompatActivity{
    @Inject
    Lazy<UploadPresenter> mPresenter1;
    @Inject
    Provider<UploadPresenter> mPresenter2;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //注入实例
        DaggerUploadActivityComponent.builder()
            .build()
            .inject(this);
    }

    public void xxx(){
         //调用Lazy的get()方法后才开始初始化Presenter并得到该实例
         //并且后面每次调用get()方法得到的实例都将是同一个。
         mPresenter1.get().xxx();

         //调用Provider的get()方法后才开始初始化Presenter并得到该实例
         //并且后面每次调用get()方法,都会重新调用供应端的供应方法来获取新实例。
         mPresenter2.get().xxx();
    }
}
复制代码

注意: 如果使用了前面介绍的作用域注解@Scope控制了实例的唯一性,那么即使多次调用Provider的get()方法,得到的依然是同一个实例。


6. 依赖 和 包含

假设供应端某个实例的初始化过程,需要用到全局的Context(即Application),那么我们可以通过桥梁间的依赖或包含,从全局的AppComponent中获取。

@Module
public class TestActivityModule {
    //需要使用到Application参数
    @Provides
    DbHelper dbHelper(Application application){
          return new DbHelper(application);
    }
}
复制代码

6.1 通过依赖实现(TestActivityComponent依赖AppComponent)

通过dependencies = xxx.classs指定要依赖的Component :

@Component(modules = TestActivityModule.class, dependencies = AppComponent.class)
public interface TestActivityComponent {
   void inject(TestActivity testActivity);
}
复制代码

被依赖的Component中需定义相关实例的获取方法 :

@Singleton
@Component(modules = AppModule.class)
public interface AppComponent {

    Application application();
    ...
}
复制代码

初始化TestActivityComponent时需传入依赖的Component

public class TestActivity extends AppCompatActivity{

    @Inject
    DbHelper mDbHelper;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        DaggerTestActivityComponent.builder()
            .appComponent(MyApplication.mAppComponent) //传入依赖的Component
            .build()
            .inject(this);
    }    
}
复制代码

6.2 通过包含实现(AppComponent包含TestActivityComponent)

TestActivityComponent使用@Subcomponent注解而不是@Component

@Subcomponent(modules = TestActivityModule.class)
public interface TestActivityComponent {
    void inject(TestActivity testActivity);
}
复制代码

AppComponent中定义相关方法,用来包含和获取SubComponent

@Singleton
@Component(modules = AppModule.class)
public interface AppComponent {

    TestActivityComponent addSub(TestActivityModule testActivityModule);
    ...
}
复制代码

通过AppComponent来获取SubComponent,然后注入

public class TestActivity extends AppCompatActivity{

    @Inject
    DbHelper mDbHelper;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        TestActivityComponent testActivityComponent = MyApplication.mAppComponent.addSub(new TestActivityModule());
        testActivityComponent .inject(this);
            
    }    
}
复制代码

6.3 依赖和包含使用小结

  • 通过桥梁Component之间的依赖或包含,可以获取到其他桥梁所连接的供应端提供的实例。
  • 使用依赖实现的话(假设A依赖B),A需通过dependencies指定依赖B,B中需定义A所需的相关实例的获取方法,A构造时需传入B。
  • 使用包含实现的话(假设B包含A),A需使用@Subcomponent标注,B中需定义方法来包含/获取A,A是通过调用B的方法来获取的。
  • 具有依赖关系的两个Component,它们的作用域注解@Scope必须不同,否则会引起歧义。

7. 一些Tips

7.1
在1.3.1和1.3.2介绍了两种实例供应方式:使用Module(方式一)、使用@Inject标注构造函数(方式二)。

那什么时候应该使用哪种方式呢? 假设现在供应端需要提供A类的实例

  • 当无法在A类的构造函数上加入@Inject时(比如一些第三方库里的类),则使用方式一提供A实例。
  • 当你希望在A类实例初始化时,A类中被@Inject标注的变量也被自动注入,则使用方式二提供A实例。

7.2
Module类可以声明为abstract抽象,但相关的供应方法需声明为static静态方法。

7.3
如果module中的供应方法声明了@Scope,那么它所属的component必须也声明相同的@Scope。 但如果component声明了@Scope,它的module的供应方法并不一定全都要声明@Scope。

7.4
@inject标注的实例变量不能声明为private,也不能为static,否则会编译报错。


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值