概述，学Dagger2-Android的理由

Dagger2的窘境

在使用Dagger2进行Android开发时，不可避免的问题是我们需要实例化一些Android系统的类，比如Activity或者Fragment。最理想的情况是Dagger能够创建所有需要依赖注入的对象，但事实上，我们不得不在容器的声明周期中声明这样的代码：

public class FrombulationActivity extends Activity {
  @Inject Frombulator frombulator;

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    // DO THIS FIRST. Otherwise frombulator might be null!
    ((SomeApplicationBaseType) getContext().getApplicationContext())
        .getApplicationComponent()
        .newActivityComponentBuilder()
        .activity(this)
        .build()
        .inject(this);
    // ... now you can write the exciting code
  }
}

这样的确可以实现Android的依赖注入，但还有两个问题需要我们去面对：

1.即使Dagger使我们的代码耦合性更低，但是如果要面临重构，我们仍然不得不去面对每个Activity中这样数行需要我们「复制」+「粘贴」的代码，这会给我们的重构带来一定的难度（试想一下，如果我们的应用有数十个乃至上百个这样的Activity或者Fragment容器，我们的重构计划，首先就要面对这样数百行的代码）。
并且随着新的开发人员加入（他们也许并不知道这些代码的意义，但是他们会复制粘贴），越来越少的人知道这些代码都干了些什么。
2.更重要的是，它要求注射类型（FrombulationActivity）知道其注射器。 即使这是通过接口而不是具体类型完成的，它打破了依赖注入的核心原则：一个类不应该知道如何实现依赖注入。

瑕不掩瑜！

诚如标题所言，虽然Dagger2在Android开发中有一些问题，但是它强大的功能依然使得开发人员趋之若鹜，无数的工程师们尝试弥补Dagger的这个问题，于是Dagger2-Android,基于Dagger2，应用于Android开发，由google开发的的拓展库应运而生。

本文结构

  1. 概述，我们学Dagger2-Android的理由
  2. 应用，Dagger2-Android入门Demo
  3. 重构，基于google官方demo的优化尝试
  4. 源码分析，知其然亦要知其所以然
  5. 总结
「提示」本文篇幅较长，且和Dagger2的使用有一定的区别（需要额外的学习成本），若您觉得本文尚可，建议收藏慢慢阅读
「知识储备」本文可能需要您对Dagger2有足够的了解

如果您对Dagger2一些知识点不熟悉，可以尝试看一下笔者的Dagger2相关文章：

Dagger2使用详解（四）Scope注解的使用及源码分析

Dagger2使用详解（三）进阶篇 MVP架构下的使用

Dagger2使用详解（二）Module&Component源码分析

Dagger2使用详解（一）基础使用

应用，Dagger2-Android入门Demo

1.环境&依赖

    annotationProcessor 'com.google.dagger:dagger-compiler:2.11' //一定要添加dagger2的annotationProcessor！
    compile 'com.google.dagger:dagger-android:2.11'
    compile 'com.google.dagger:dagger-android-support:2.11' // if you use the support libraries
    annotationProcessor 'com.google.dagger:dagger-android-processor:2.11

2.Demo结构分析

首先我们先看看Demo效果

这里写图片描述

结构如下：

这里写图片描述

可以看到，我们在MainActivity中需要通过依赖注入，获得4个对象，同时MainPresenter和MainModel也同样得到了实例化，我们先看下MVP这个架构中三个成员的代码：

3.MVP基本代码

MainActivity相关代码

MainActivity代码：

public class MainActivity extends BaseActivity implements MainContract.View {

    @Inject
    String className;
    @Inject
    Student student;
    @Inject
    SharedPreferences sp;
    @Inject
    MainPresenter presenter;

    @BindView(R.id.tv_content)
    TextView tvContent;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);

        //下面这行代码把所有实例化的对象展示在界面中
        tvContent.setText(className + "\n" +
                student.toString() + "\n" +
                sp.toString() + "\n" +
                presenter.toString());
    }

     //省略其他代码

显然，从结果来看，我们根本没有在Activity中添加上文所述的模板代码：

    //就是这些，模板代码
    ((SomeApplicationBaseType) getContext().getApplicationContext())
        .getApplicationComponent()
        .newActivityComponentBuilder()
        .activity(this)
        .build()
        .inject(this);

MainPresenter代码：

public class MainPresenter implements MainContract.Presenter {

    private final MainActivity view;
    private final MainModel model;

    @Inject
    public MainPresenter(MainActivity view, MainModel model) {
        this.view = view;
        this.model = model;
    }

    //省略其他代码
}

MainModel代码：

public class MainModel implements MainContract.Model {

    @Inject
    public MainModel() {
    }

   //省略其他代码
}

和Dagger2的使用没有区别，其根本原理，都是通过@Inject注解，使Dagger2自动生成对应的工厂类，以提供MainPresenter和MainModel的实例。

SecondActivity代码

和MainActivity基本一样，为了简便我们只注入了一个String，用来展示类名（请参照上面的gif图）：

public class SecondActivity extends BaseActivity {

    @Inject
    String className;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        TextView tv = (TextView) findViewById(R.id.tv_content);
        tv.setText(className);
    }
}

可以看到，我们依然没有添加冗余的模板代码，试想，一个app中这样几十个Activity容器都不需要这样的模板代码，我们的工作量确实减少了很多，同时，也达到了我们的目的，即：

依赖注入的核心原则：一个类不应该知道如何实现依赖注入。

实际上，我们只是在BaseActivity中，添加了这样一行代码，就实现了我们想要的效果

public class BaseActivity extends AppCompatActivity{

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        AndroidInjection.inject(this);  //一处声明，处处依赖注入
        super.onCreate(savedInstanceState);
    }
}
接下来，让我们看看Dagger2-Android 的Module和Component怎么写

参考:谷歌官方Demo https://google.github.io/dagger//android.html

4.Module和Component

首先我们先声明对应Activity的Module和Component：

MainActivity依赖配置

我们声明Subcomponent,其关联的module可以提供MainActivity所需要的所有依赖的实例。

@Subcomponent(modules = {
        AndroidInjectionModule.class,
        MainActivitySubcomponent.SubModule.class
})
public interface MainActivitySubcomponent extends AndroidInjector<MainActivity> {

    @Subcomponent.Builder
    abstract class Builder extends AndroidInjector.Builder<MainActivity> {
    }

    @Module
    class SubModule {

        @Provides
        String provideName() {
            return MainActivity.class.getName();
        }

        @Provides
        Student provideStudent() {
            return new Student();
        }

        @Provides
        SharedPreferences provideSp(MainActivity activity) {
            return activity.getSharedPreferences("def", Context.MODE_PRIVATE);
        }

        @Provides
        MainModel provideModel() {
            return new MainModel();
        }
    }
}

然后我们创建MainActivityModule

@Module(subcomponents = MainActivitySubcomponent.class)
public abstract class MainActivityModule {

    @Binds
    @IntoMap
    @ActivityKey(MainActivity.class)
    abstract AndroidInjector.Factory<? extends Activity>
    bindMainActivityInjectorFactory(MainActivitySubcomponent.Builder builder);

}

ok,这样MainActivity的相关依赖注入配置完毕。

SecondActivity依赖配置

同理，Subcomponent代码如下：

@Subcomponent(modules = {
        SecondActivitySubcomponent.SubModule.class,
        AndroidInjectionModule.class,
})
public interface SecondActivitySubcomponent extends AndroidInjector<SecondActivity> {

    @Subcomponent.Builder
    abstract class Builder extends AndroidInjector.Builder<SecondActivity> {
    }

    @Module
    class SubModule {
        @Provides
        String provideName() {
            return SecondActivity.class.getName();
        }
    }
}

然后是Model

@Module(subcomponents = SecondActivitySubcomponent.class)
public abstract class SecondActivityModule {

    @Binds
    @IntoMap
    @ActivityKey(SecondActivity.class)
    abstract AndroidInjector.Factory<? extends Activity>
    bindSecondActivityInjectorFactory(SecondActivitySubcomponent.Builder builder);

}

各个模块配置完毕，接下来我们将上述的Module组合起来即可：

全局依赖配置

我们先声明我们的Application类，然后一定要记得添加到清单文件中：

public class MyApplication extends Application implements HasActivityInjector {

    @Inject
    DispatchingAndroidInjector<Activity> dispatchingAndroidInjector;

    @Override
    public void onCreate() {
        super.onCreate();
        //DaggerMyAppComponent.create().inject(this);
    }

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

}

请注意，我们在这里做了几件事：

1.实现HasActivityInjector接口

2.实现HasActivityInjector接口的activityInjector()方法

3.声明一个泛型为Activity的DispatchingAndroidInjector成员变量并在activityInjector()方法中返回

这里我们注释掉了一行代码，因为我们要先写AppComponent接口，然后编译，才能让编译器自动生成DaggerMyAppComponent类。

@Component(modules = {
        AndroidInjectionModule.class,
        AndroidSupportInjectionModule.class,
        MainActivityModule.class,
        SecondActivityModule.class
})
public interface MyAppComponent {

   void inject(MyApplication application);
}

请注意，我们在这里做了几件事：

1.在这个Component中添加了 AndroidInjectionModule 和 AndroidSupportInjectionModule

2.同时添加了MainActivityModule 和 SecondActivityModule的依赖

3.声明注入方法inject，参数类型为MyApplication

好的，所有配置全部结束，我们使用ctrl+F9（Mac:cmd+F9）进行编译,然后打开MyApplication中注释的那行代码，运行app，依赖注入成功，如上文gif图所示。

5.除Activity之外，Dagger-Android还提供了Fragment，BroadCast,Service等其他组件的注入方式，详情请参照官方网站，本文不赘述。

https://google.github.io/dagger//android.html

6.注意

如果您按照本文中的代码实现，并没有得到对应的效果或者编译错误，请仔细检查是否严格按照本文的步骤进行编码，如果还有问题，建议您直接拉到本文最下方，下载源码查看。

重构，基于google官方demo的优化尝试

1.还有一些冗余代码

上述章节中的使用方式基本是按照谷歌官方的guide进行的依赖注入，实际上个人认为还有几点可以优化：

1.多余的ActivityModule

请参照上文的MainActivityModule和SecondActivityModule,实际上从根本上来说，也类似模板代码，当界面多了，会生成大量的java文件

2.多余的Subcomponent
同理，太多了。

3.越来越庞大的AppComponent
当Activity越来越多，AppComponet中的注解会变成这样：

@Component(modules = {
        AndroidInjectionModule.class,
        AndroidSupportInjectionModule.class,
        MainActivityModule.class,
        SecondActivityModule.class
        ...
        ...//中间省略不知道多少行
        XXActivityModule.class
})

我们来看看目前的结构：
这里写图片描述

可以看到，很冗余，实质上，表面上的注入器（Appcomponent）,和对象的提供者（MainSubComponent.SubModule）两者起到了至关重要的作用，而Module和SubComponent作用不大。

2.假设

于是我们联想，我们可不可以改变结构成这样呢：

这里写图片描述

简述如下：

1.AppComponent的module:AllActivityModule，其负责所有ActivityModule实例的管理

2.BaseActivityComponent为AllActivityModule的subcomponent,管理了提供各activity所需对象的module

3.MainActivityModule 负责提供所有对应Activity所需要对象实例的提供。

3.实装

首先，创建BaseActivityComponent，并将所有的ActivitySubcomponent删除：
@Subcomponent(modules = {
        AndroidInjectionModule.class,
})
public interface BaseActivityComponent extends AndroidInjector<BaseActivity> {
    //每一个继承BaseActivity的Activity，都共享同一个SubComponent
    @Subcomponent.Builder
    abstract class Builder extends AndroidInjector.Builder<BaseActivity> {
    }

}
然后我们将对应的对象提供放到ActivityModule里：

MainActivityModule:

@Module
public class MainActivityModule {

    @Provides
    static String provideName() {
        return MainActivity.class.getName();
    }

    @Provides
    static SharedPreferences provideSp(MainActivity activity) {
        return activity.getSharedPreferences("def", Context.MODE_PRIVATE);
    }
    //其他对象的提供 省略
}

SecondActivityModule:

@Module
public abstract class SecondActivityModule {

    @Provides
    static String provideName() {
        return SecondActivity.class.getName();
    }

}

那么问题来了，我们原本放在这里面的这些代码怎么办呢，例如：

    @Binds
    @IntoMap
    @ActivityKey(SecondActivity.class)
    abstract AndroidInjector.Factory<? extends Activity>
    bindSecondActivityInjectorFactory(SecondActivitySubcomponent.Builder builder);
新建AllActivitysModule，并统统放入其中统一管理：
@Module(subcomponents = {
        BaseActivityComponent.class
})
public abstract class AllActivitysModule {

    @ContributesAndroidInjector(modules = MainActivityModule.class)
    abstract MainActivity contributeMainActivitytInjector();

    @ContributesAndroidInjector(modules = SecondActivityModule.class)
    abstract SecondActivity contributeSecondActivityInjector();

}

这样，我们每次新建一个Activity，只需要统一在这里新建2行代码声明对应的Activity即可。

对个人而言，这样的好处在于：
1.每次不再需要额外声明一个SubCompoent，再次减少模板代码
2.每个Activity的Module都放在同一个AllActivitysModule中进行统一管理，每次修改只需要修改这一个类即可
3.每个Activity所单独需要的依赖，依然由各自的Module进行管理和实例化，依然没有任何耦合

关于这两行代码的解释，请参考官网：https://google.github.io/dagger//android.html

Pro-tip: If your subcomponent and its builder have no other methods or supertypes than the ones mentioned in step #2, you can use @ContributesAndroidInjector to generate them for you. Instead of steps 2 and 3, add an abstract module method that returns your activity, annotate it with @ContributesAndroidInjector, and specify the modules you want to install into the subcomponent. If the subcomponent needs scopes, apply the scope annotations to the method as well.

@ActivityScope
@ContributesAndroidInjector(modules = { /* modules to install into the subcomponent */ })
abstract YourActivity contributeYourActivityInjector();

最后修改AppComponent
@Component(modules = {
        AndroidInjectionModule.class,
        AndroidSupportInjectionModule.class,
        AllActivitysModule.class    
})
public interface MyAppComponent {

    void inject(MyApplication application);
}
修改完毕，大功告成！

好的，所有配置全部结束，我们使用ctrl+F9（Mac:cmd+F9）进行编译,然后打开MyApplication中注释的那行代码，运行app，依赖注入依旧成功。

不同的是，这次我们的模板代码更少了。

源码分析，知其然亦要知其所以然

一路写下来，单单该库的使用，竟然洋洋洒洒竟然写了这么多，实在超出预料。

// 源码分析，鉴于篇幅所限，准备另起一篇文章改日慢慢分析。 2017/8/22

2017/8/30更新

源码分析，鉴于篇幅所限，另起一篇文章，请阅读本文：

Dagger-Android详解&源码分析

总结

看了这么多，有的朋友可能会看了几眼就不看了，也一定会有人觉得笔者啰嗦，文笔有限，但还是希望能够给大家提供一定的帮助，毕竟关于这个库，国内的中文相关资料实在有限，而Dagger依赖注入库的学习成本，也是出了名的高。

最后提供一下本文demo源码连接：

https://github.com/qingmei2/Sample_dagger2

# android
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生