安卓基础开发库，让开发简单点。

DevRing & Demo地址：

学习/参考地址：
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实例的构造过程移至实例供应端，则功能实现模块的代码会变成这样

@InjcetA 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标注方法，表示它为提供实例的方法。在该方法中对实例进行初始化并返回该实例。

@Modulepublic 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. 接收外部参数

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

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

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

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

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

对实例供应端的module进行改造

@Modulepublic 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，一个用于登录，一个用于注册。

@Modulepublic 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注解的话，需要加入字符串来区分，这样比较麻烦也容易出错。所以我们可以使用自定义的限定符注解。

@Qualifierpublic @interface DialogLogin {}复制代码

@Qualifierpublic @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 供应端中提供实例的方法添加作用域注解

@Modulepublic class UploadActivityModule {    @ActivityScope    @Provides    UploadPresenter uploadPresenter() {        return new UploadPresenter();    }}复制代码

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

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

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

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

全局单例，相信大家就很熟悉了，就是平时用饿汉懒汉等等写的那种单例模式。

前面已经说过@Scope作用是使同一个Component中供应的实例保持唯一。

也就是说，如果我在另一个Activity中再创建了一个新的Component，那么它所提供的UploadPresenter实例也将是新的。

这和我们理解的全局单例并不一样。

所以，要想实现全局单例，那就要确保获取实例的Component一直都是同一个。

如何实现呢？答案是创建一个Component用于提供全局单例的实例，然后在Application中对该Component进行初始化，以后要获取单例时，都统一通过它来获取。

全局性的实例供应端

@Modulepublic 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
    
      mPresenter1;    @Inject    Provider
     
       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中获取。

@Modulepublic 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，否则会编译报错。

前言