美文网首页
依赖注入利器 - Dagger ‡

依赖注入利器 - Dagger ‡

作者: 陈HHH | 来源:发表于2019-11-13 11:19 被阅读0次

    概述

    在开发过程中,为了实现解耦,我们经常使用依赖注入,常见的依赖注入方式有:

    • 构造方法注入:在构造方法中把依赖作为参数传递进去
    • setter方法注入:添加setter方法,把依赖传递进去
    • 接口注入:把注入方法抽到一个接口中,然后实现该接口,把依赖传递进去

    下面用一个小栗子来说明三种方式的用法:

    public class PersonService implements DependencyInjecter {
    
        private PersonDao personDao;
    
        // 构造方法注入
        public PersonService(PersonDao personDao) {
            this.personDao = personDao;
        }
    
        // setter方法注入
        public void setPersonDao(PersonDao personDao) {
            this.personDao = personDao;
        }
    
        // 接口注入:实现DependencyInjecter接口
        @Override
        public void injectPersonDao(PersonDao personDao) {
            this.personDao = personDao;
        }
    
        ... ... 
    }
    

    我们来看下使用一般的依赖注入方法时,代码会是怎么样的:

    public class MainActivity extends AppCompatActivity {
    
        private PersonService mService;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            // 创建PersonService的依赖:personDao
            PersonDao personDao = new PersonDaoImpl();
            // 通过构造方法注入依赖
            mService = new PersonService(personDao);
        }
    }
    

    看起来还好是吧?但现实情况下,依赖情况往往是比较复杂的,比如很可能我们的依赖关系如下图:


    2019-9-2-11-38-41.png

    PersonDaoImpl依赖类A,类A依赖B,B依赖C和D...在这种情况下,我们就要写出下面这样的代码了:

    public class MainActivity extends AppCompatActivity {
    
        private PersonService mService;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            // 创建依赖D
            D d = new D();
            // 创建依赖C
            C c = new C();
            // 创建依赖B
            B b = new B(c, d);
            // 创建依赖A
            A a = new A(b);
            // 创建PersonService的依赖:personDao
            PersonDao personDao = new PersonDaoImpl(a);
            // 通过构造方法注入依赖
            mService = new PersonService(personDao);
        }
    }
    

    MainActivity只是想使用PersonService而已,却不得不关注PersonService的依赖是什么、PersonDaoImpl依赖的依赖是什么,需要把整个依赖关系搞清楚才能使用PersonService。而且还有一个不好的地方,一旦依赖关系变更了,比如A不再依赖B了,那么就得修改所有创建A的地方。那么,有没有更好的方式呢?Dagger就是为此而生的,让我们看看使用Dagger后,MainActivity会变成什么模样:

    public class MainActivity extends AppCompatActivity {
    
        @Inject
        PersonService mService;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            // Dagger注入,读者现在可先不关注里面做了什么操作
            DaggerPersonServiceComponent.create().inject(MainActivity.this);
    
            // 注意,mService已经是非空了,可以正常使用
            mService.update(1, "HansChen");
            ......
        }
    }
    

    之前创建A、B、C、D、PersonDaoImpl等依赖的代码全不见了,只需要调用一个注入语句就全搞定了。调用了注入语句之后,mService就可以正常使用了,是不是挺方便呢?至于这句注入语句具体干了什么,读者现在可以先不管,后面会有详细说明,这里只是做一个使用演示而已。

    我们大概猜想一下,在MainActivity使用PersonService需要做哪些?

    1. 分析生成依赖关系图,如PersonService-->PersonDaoImpl-->A-->B-->C&D
    2. 根据依赖关系图获取相关依赖,比如依次创建D、C、B、A、PersonDaoImpl、PersonService的实例
    3. 把生成的PersonService实例传递给MainActivity的mService成员变量

    其实Dagger做的也就是上面这些事情了,接下来就让我们真正开始学习Dagger吧

    声明需要注入的对象

    首先我们应该用javax.inject.Inject去注解需要被自动注入的对象,@Inject是Java标准的依赖注入(JSR-330)注解。比如下面栗子中,需要注入的对象就是MainActivity的mService。这里有个要注意的地方,被@Inject注解的变量不能用private修饰

    public class MainActivity extends AppCompatActivity {
    
        // 注意,不能被private修饰
        @Inject
        PersonService mService;
        ......
    }
    

    如何实例化出依赖?

    在执行依赖注入的时候,Dagger会查找@Inject注解的成员变量,并尝试获取该类的实例,Dagger最直接的方式就是直接new出相应的对象了。实例化对象的时候,会调用对象的构造方法,但假如有多个构造方法,具体用哪个构造方法来实例化对象?Dagger肯定是不会帮我们“擅自做主”的,用哪个构造方法来实例化对象应该是由我们做主的,所以我们需要给相应的构造方法添加@Inject注解
    当Dagger需要实例化该对象的时候,会调用@Inject注解的构造方法来实例化对象:

    public class PersonService implements DependencyInjecter {
    
        private PersonDao personDao;
    
        // 用@Inject注解,相当于告诉Dagger需要实例化PersonService的时候,请调用这个构造方法
        @Inject
        public PersonService(PersonDao personDao) {
            this.personDao = personDao;
        }
    
        ......
    }
    

    聪明的你应该发现了,调用PersonService的构造方法需要传入PersonDao实例,所以要实例化PersonService,必须先要实例化PersonDao,Dagger会帮我们自动分析出这个依赖关系,并把它添加到依赖关系图里面!Dagger会尝试先去实例化一个PersonDao,如果PersonDao又依赖于另外一个对象A,那么就先尝试去实例化A......以此类推,是不是很像递归?当所有依赖都被实例化出来之后,我们的PersonService当然也被构造出来了。

    问题又来了,如果PersonDao是一个接口呢?Dagger怎么知道这个接口应该怎么实现?答案是不知道的,那么Dagger怎么实例化出一个接口出来?这个就是Module存在的意义之一了。关于Module的讲解我们会在后面详细说明,我们现在只要知道,Module里面会定义一些方法,这些方法会返回我们的依赖,就像:

    @Module
    public class PersonServiceModule {
    
        /**
         * 提供PersonDao接口实例
         */
        @Provides
        PersonDao providePersonDao(A a) {
            return new PersonDaoImpl(a);
        }
    }
    

    Dagger根据需求获取一个实例的时候,并不总是通过new出来的,它会优先查找Module
    中是否有返回相应实例的方法,如果有,就调用Module的方法来获取实例。

    比如你用@Inject注解了一个成员变量,Dagger会查找Module中是否有用@Provides注解的,返回该类实例的方法,有的话就会调用provide方法来获得实例,然后注入,如果没有的话Dagger就会尝试new出一个实例。就像我们现在这个栗子,PersonService依赖于PersonDao接口,Dagger不能直接为我们new出一个接口,但我们可以提供一个Module,在Module中定义一个返回PersonDao接口实例的方法,这样,Dagger就可以解决实例化PersonDao的问题了。

    我们再梳理一下流程,如果我们用@Inject注解了一个成员变量,并调用注入代码之后,Dagger会这样处理:

    1. 查找Module中是否有用@Provides注解的,返回该类实例的方法
    2. 如果有,就调用那个provide方法来获得实例,然后注入
    3. 如果没有,就尝试调用相应的类中被@Inject注解的构造方法new出一个实例,然后注入
    4. 如果没有一个构造方法被@Inject注解,Dagger会因不能满足依赖而出错

    所以假如一个变量被@Inject注解,要么在Module中提供provide方法获取实例,要么该类提供一个被@Inject注解的构造方法,否则Dagger会出错

    Module的使用

    一般而言,Dagger会获取所有依赖的实例,比如当需要一个TestBean的时候,会通过new TestBean()创建实例并注入到类中。但是,以下情况会就不好处理了:

    1. 需要生成的是一个接口,而Dagger不能直接实例化接口
    2. 不能在第三方库的类中添加注解
    3. 可配置的对象必须是配置的

    为了解决以上问题,我们需要定义一个被@Module注解的类,在里面定义用@Provides注解的方法。用该方法返回所需的实例。

    @Module
    public class PersonServiceModule {
    
        @Provides
        D provideD() {
            return new D();
        }
        
        @Provides
        C provideC() {
            return new C();
        }
    
        @Provides
        B provideB(C c, D d) {
            return new B(c, d);
        }
    
        @Provides
        A provideA(B b) {
            return new A(b);
        }
    
        /**
         * 提供PersonDao实例
         */
        @Provides
        PersonDao providePersonDao(A a) {
            return new PersonDaoImpl(a);
        }
    }
    

    就像providePersonDao返回了PersonDao接口实例,Dagger虽然不能直接实例化出PersonDao接口,但却可以调用Module的providePersonDao方法来获得一个实例。providePersonDao方法需要传入A的实例,那么这里也构成了一个依赖关系图。Dagger会先获取A的实例,然后把实例传递给providePersonDao方法。

    Component的使用

    到目前为止,我们虽然知道了:

    • Dagger怎么获取实例:
      • 从Module的provide方法中获取
      • 通过@Inject注解的构造方法new出新的实例
    • Dagger会推导provide方法和构造方法的参数,形成依赖图,并“满足”我们依赖图的需求,获取依赖的实例

    看样子需要注入的依赖可以获取了,但是不是总觉得还有点“零碎”,整个流程还没连贯起来?比如,Module既然是一个类,生成依赖图的时候,怎么知道跟哪个Module挂钩?即使最后生成了需要的实例,注入的“目的地”是哪里?怎么才能把它注入到“目的地”?残缺的这部分功能,正是Component提供的,Component起到了一个桥梁的作用,贯通Module和注入目标。我们来看看最开始那个例子,我们是怎么进行依赖注入的:

    public class MainActivity extends AppCompatActivity {
    
        @Inject
        PersonService mService;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            PersonServiceComponent component = DaggerPersonServiceComponent.builder()
                                                                           .personServiceModule(new PersonServiceModule())
                                                                           .build();
            // 注入,所有@Inject注解的成员变量都会同时注入
            component.inject(MainActivity.this);
    
            // 通过component获取实例,注意,这里只是演示用法,其实mService在component.inject的时候已经完成了注入
            mService = component.getPersonService();
        }
    }
    

    这个DaggerPersonServiceComponent是什么鬼?DaggerPersonServiceComponent其实是Dagger为我们自动生成的类,它实现了一个Component接口(这个接口是需要我们自己写的),我们来看下它实现的接口长什么样子:

    /**
     * 指定PersonServiceModule,当需要获取某实例的时候,会查找PersonServiceModule中是否有返回相应类型的方法,有的话就通过该方法获得实例
     *
     * @author HansChen
     */
    @Component(modules = PersonServiceModule.class)
    public interface PersonServiceComponent {
    
        /**
         * 查找activity中被@Inject注解的成员变量,并尝试获取相应的实例,把实例赋给activity的成员变量
         * 注意函数格式:返回值为空、带有一个参数
         */
        void inject(MainActivity activity);
    
        /**
         * Dagger会尝试从Module中获取PersonService实例,如果Module中不能获取对应实例,则通过PersonService的构造方法new出一个实例
         * 注意函数格式:参数为空,返回值非空
         */
        PersonService getPersonService();
    }
    

    这个接口被Component注解修饰,它里面可以定义3种类型的方法:

    • 返回值为空,有一个参数:查找参数中被@Inject注解的成员变量,并尝试获取相应的实例(通过Module的provide方法或@Inject注解的构造方法new出新的实例),把实例赋给参数的成员变量
    • 返回值非空,参数为空:获取相应实例并返回
    • 返回值是Component,参数是Moduld,通过该方法可以创建SubComponent实例

    既然获取实例的时候,有可能用到Module,那么就必须为这个Component指定使用的Module是什么。具体做法就是在@Component注解中指定modules。
    定义好Component之后,Dagger会自动帮我们生成实现类,这就是Dagger强大的地方!生成的类名格式是:Dagger+Component名。
    Component提供了2种方法,一个是注入式方法,一个是获取实例方法。具体用什么方法,就看个人需求了。一个Component其实也对应了一个依赖图,因为Component使用哪个Module是确定不变的,依赖关系无非也就是跟Module和类的定义有关。一旦这些都确定下来了,在这个Component范围内,依赖关系也就被确定下来了。额外再说一点,在Dagger1中,Component的功能是由ObjectGraph实现的,Component是用来代替它的。

    Component定义好之后,build一下工程,Dagger就会自动为我们生成实现类了,就可以使用自动生成的实现类来进行依赖注入了。到现在为止,我们已经通过Dagger完成了依赖注入。可能看起来比正常方法麻烦得多,但是Dagger框架可以让依赖的注入和配置独立于组件之外,它帮助你专注在那些重要的功能类上。通过声明依赖关系和指定规则构建整个应用程序。

    熟悉完Dagger基本的使用之后,接下来我们来讲解一些稍微高级一点的用法:

    Dagger的进阶使用

    Components之间的关系

    在Dagger中,Component之间可以有两种关系:Subcomponents和Component dependencies。他们有什么作用呢?比如在我们应用中,经常会有一些依赖我们在各个界面都使用得到,比如操作数据库、比如网络请求。假设我们有个ServerApi的接口,在页面A、B、C都使用到了,那么我们要在页面A、B、C的Component里面都能获取到ServerApi的实例,但显然,获取ServerApi实例的方法都是一样的,我们不想写重复的代码。于是我们可定义一个ApplicationComponent,在里面返回ServerApi实例,通过Component之间的关系便可以共享ApplicationComponent提供的依赖图。

    下面通过Android中的一个小栗子来说明Subcomponents和Component dependencies如何使用

    dependencies

    先说明下各个模块之间的关系
    首先,我们定义一个ApplicationComponent,它定义了一个方法,通过它来获得ServerApi实例。ApplicationComponent还关联了ApplicationModule,这个Module是ServerApi实例的提供者,注意,这个Moduld还可以返回Context实例


    2019-9-2-11-41-18.png
    @Component(modules = ApplicationModule.class)
    public interface ApplicationComponent {
    
        ServerApi getServerApi();
    }
    
    @Module
    public class ApplicationModule {
    
        private final Context mAppContext;
    
        ApplicationModule(Context context) {
            mAppContext = context.getApplicationContext();
        }
    
        @Provides
        Context provideAppContext() {
            return mAppContext;
        }
    
        @Provides
        ServerApi provideServerApi(Context context) {
            return new ServerApiImpl(context);
        }
    }
    
    public class DemoApplication extends Application {
    
        private ApplicationComponent mAppComponent;
    
        @Override
        public void onCreate() {
            super.onCreate();
            mAppComponent = DaggerApplicationComponent.builder().applicationModule(new ApplicationModule(this)).build();
        }
    
        public ApplicationComponent getAppComponent() {
            return mAppComponent;
        }
    }
    

    MainActivity使用MVP模式,在MainPresenter里面需要传入一个ServerApi对象


    2019-9-2-11-43-13.png
    // 注意,这里有个dependencies声明
    @Component(dependencies = ApplicationComponent.class, modules = MainPresenterModule.class)
    public interface MainPresenterComponent {
    
        MainPresenter getMainPresenter();
    }
    
    @Module
    public class MainPresenterModule {
    
        private MainView mMainView;
    
        public MainPresenterModule(MainView mainView) {
            this.mMainView = mainView;
        }
    
        @Provides
        MainView provideMainView() {
            return mMainView;
        }
    }
    
    public class MainPresenter {
    
        private MainView  mMainView;
        private ServerApi mServerApi;
    
        @Inject
        public MainPresenter(MainView mainView, ServerApi serverApi) {
            this.mMainView = mainView;
            this.mServerApi = serverApi;
        }
    }
    

    先抛开dependencies,我们分析这个这个依赖树是怎么样的


    2019-9-2-11-43-43.png

    Component中getMainPresenter的目的很简单,就是返回MainPresenter,而MainPresenter又依赖MainView和ServerApi,MainView还好说,在MainPresenterModule中有provide方法,但是ServerApi呢?就像上面说的那样,如果我们在这个Moduld中也添加相应的provide方法,那真是太麻烦了(当然,这样做完全是可以实现的),所以我们依赖了ApplicationComponent,通过dependencies,在被依赖的Component暴露的对象,在子Component中是可见的。这个是什么意思呢?意思有两个:

    1. 被依赖Component接口暴露的对象,可以添加到依赖者的依赖图中
    2. Component接口没有暴露的对象,依赖者是不可见的

    对于第一点应该比较好理解,就像这个栗子,MainPresenterComponent生成MainPresenter需要ServerApi,而ApplicationComponent中有接口暴露了ServerApi,所以MainPresenterComponent可以获得ServerApi
    对于第二点,假设MainPresenter还需要传入一个Context对象,我们注意到,ApplicationModule是可以提供Context的,那MainPresenterComponent能不能通过ApplicationComponent获取Context实例?答案是不行的,因为ApplicationComponent没有暴露这个对象。想要获取Context,除非ApplicationComponent中再添加一个getContext的方法。

    他们之间的关系可以用下图描述:


    2019-9-2-11-44-12.png

    Subcomponents

    Subcomponents 实现方法一:

    • 先定义子 Component,使 用@Subcomponent 标注(不可同时再使用 @Component)
    • 父 Component 中定义获得子 Component 的方法

    让我们对上面的栗子改造改造:
    去除MainPresenterComponent的Component注解,改为Subcomponent:

    @Subcomponent(modules = MainPresenterModule.class)
    public interface MainPresenterComponent {
    
        void inject(MainActivity activity);
    
        MainPresenter getMainPresenter();
    }
    

    在ApplicationComponent中新增plus方法(名字可随意取),返回值为MainPresenterComponent,参数为MainPresenterModule:

    @Component(modules = ApplicationModule.class)
    public interface ApplicationComponent {
    
        MainPresenterComponent plus(MainPresenterModule module);
    }
    

    这样,就构建了一个ApplicationComponent的子图:MainPresenterComponent。子图和dependencies的区别就是,子图可以范围父图所有的依赖,也就是说,子图需要的依赖,不再需要在父Component中暴露任何对象,可以直接通过父图的Moduld提供!他们的关系变为了:


    2019-9-2-11-44-34.png

    这里需要注意的是,以上代码直接在父 Component 返回子 Component 的形式,要求子 Component 依赖的 Module 必须包含一个无参构造函数,用以自动实例化。如果 Module 需要传递参数,则需要使用 @Subcomponent.builder 的方式,实现方法二实现步骤如下:

    • 在子 Component,定义一个接口或抽象类(通常定义为 Builder),使用 @Subcomponent.Builder 标注
      • 编写返回值为 Builder,方法的参数为需要传入参数的 Module
      • 编写返回值为当前子 Component的 无参方法
    • 父 Component 中定义获得子 Component.Builder 的方法

    代码如下:

    @Module
    public class TestModule {
        public TestModule(String test) {
        }
    
        @Provides
        AuthManager provideAuthManager() {
            return AuthManager.getInstance();
        }
    }
    
    @Subcomponent(modules = {TestModule.class})
    public interface TestComponent {
    
        AuthManager getAuthManager();
    
        @Subcomponent.Builder
        interface Builder {
    
            Builder createBuilder(TestModule module);
    
            TestComponent build();
        }
    }
    
    @Singleton
    @Component(modules = ApplicationModule.class)
    public interface ApplicationComponent {
        ...
        TestComponent.Builder testComponentBuilder();
    }
    
    
    // 使用
    TestComponent testComponent = mApplicationComponent.testComponentBuilder().createBuilder(new TestModule("test")).build();
    

    Binds注解

    在Dagger2中,一般都是使用@provide方法注入接口。在Android 中,一般我们会这样做,创建一个接口 Presenter 命名 为 HomePresenter

    public interface HomePresenter {
       Observable<List<User>> loadUsers()
    }
    

    然后创建一个这个接口的实例:HomePresenterImp

    public class HomePresenterImp implements HomePresenter {
        public HomePresenterImp(){
        }  
        @Override
        public Observable<List<User>> loadUsers(){
            //Return user list observable
        }
    }
    

    然后在 Module 中,提供实例化的 provide 方法:

    @Module
    public class HomeModule {
        @Provides
        public HomePresenter providesHomePresenter(){
            return new HomePresenterImp();
        }
    }
    

    但是,如果我们需要添加一个依赖到 presenter 叫 UserService,那就意味着,我们也要在 module 中添加一个 provide 方法提供这个 UserService,然后在 HomePresenterImp 类中加入一个 UserService 参数的构造方法。
    有没有觉得这种方法很麻烦呢?我们还可以用 @Binds 注解,如:

    @Module
    public abstract class HomeModule {
        // 变为 abstract 方法, 同时 Module 也必须声明为 abstract, 传入的参数必须为返回参数的实现类
        // 当需要 HomePresenter 时,dagger 会自动实例化 HomePresenterImp 并返回
        @Binds
        public abstract HomePresenter bindHomePresenter(HomePresenterImp homePresenterImp);
    }
    

    除了方便,使用 @Binds 注解还可以让 dagger2 生成的代码效率更高。但是需要注意的是,由于 Module 变为抽象类,Module 不能再包含非 static 的带 @Provides 注解的方法。而且这时候,依赖此 Module 的 Component 也不需要传入此 Module 实例了(也实例化不了,因为它是抽象的)。相当于此 Module 仅仅作为描述依赖关系的一个类

    Scopes

    Scopes可是非常的有用,Dagger2可以通过自定义注解限定注解作用域。@Singleton是被Dagger预先定义的作用域注解。

    • 没有指定作用域的@Provides方法将会在每次注入的时候都创建新的对象
    • 一个没有scope的component不可以依赖一个有scope的组件component
    • 子组件和父组件的scope不能相同
    • Module中provide方法的scope需要与Component的scope一致

    我们通常的ApplicationComponent都会使用Singleton注解,也就会是说我们如果自定义component必须有自己的scope。读者到这里,可能还不能理解Scopes的作用,我们先来看下默认提供的Singlton到底有什么作用,然后再讨论Scopes的意义:

    Singlton

    Singletons是java提供的一个scope,我们来看看Singletons能做什么事情。
    为@Provides注释的方法或可注入的类添加添加注解@Singlton,构建的这个对象图表将使用唯一的对象实例,比如我们有个ServerApi
    方法一:用@Singleton注解类:

    @Singleton
    public class ServerApi {
    
        @Inject
        public ServerApi() {
        }
    
        public boolean login(String username, String password) {
            return "HansChen".equals(username) && "123456".equals(password);
        }
    }
    

    方法二:用@Singleton注解Module的provide方法:

    @Module
    public class ApplicationModule {
    
        @Singleton
        @Provides
        ServerApi provideServerApi() {
            return new ServerApi();
        }
    }
    

    然后我们有个Component:

    @Singleton
    @Component(modules = ApplicationModule.class)
    public interface ApplicationComponent {
    
        ServerApi getServerApi();
    }
    

    然后执行依赖注入:

    public class MainActivity extends AppCompatActivity {
    
        @Inject
        ServerApi mService;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            ApplicationComponent component = DaggerApplicationComponent.create();
            Log.d("Hans", component.getServerApi().toString());
            Log.d("Hans", component.getServerApi().toString());
            Log.d("Hans", component.getServerApi().toString());
        }
    }
    

    使用了以上两种方法的任意一种,我们都会发现,通过component.getServerApi()获得的实例都是同一个实例。不过要注意一点的是,如果类用@Singleton注解了,但Module中又存在一个provide方法是提供该类实例的,但provide方法没有用@Singleton注解,那么Component中获取该实例就不是单例的,因为会优先查找Module的方法。
    这个单例是相对于同一个Component而言的,不同的Component获取到的实例将会是不一样的。

    自定义Scope

    既然一个没有scope的component不可以依赖一个有scope的组件component,那么我们必然需要自定义scope来去注解自己的Component了,定义方法如下:

    @Documented
    @Scope
    @Retention(RetentionPolicy.RUNTIME)
    public @interface FragmentScoped {
    }
    

    定义出来的FragmentScoped在使用上和Singleton是一样的,那它和Singleton除了是不一样的注解之外,还有什么不一样呢?答案是没有!我们自定义的scope和Singleton并没有任何不一样,不会因为Singleton是java自带的注解就会有什么区别。

    那么,这个scope的设定是为了什么呢?

    scope的作用

    scope除了修饰provide方法可以让我们获得在同一个Component实例范围内的单例之外,主要的作用就是对Component和Moduld的分层管理以及依赖逻辑的可读性。
    这里借用一个网络上的图片说明:


    2019-9-2-11-44-58.png

    ApplicationComponent一般会用singleton注解,相对的,它的Module中provide方法也只能用singleton注解。UserComponent是用UserSCope能直接使用ApplicationModule吗?不能!因为他俩的scope不一致,这就是这个设定带来的好处,防止不同层级的组件混乱。另外,因为有了scope的存在,各种组件的作用和生命周期也变得可读起来了

    Lazy注入

    有时可能会需要延迟获取一个实例。对任何绑定的 T,可以构建一个 Lazy<T> 来延迟实例化直至第一次调用 Lazy<T> 的 get() 方法。注入之后,第一次get的时会实例化出 T,之后的调用都会获取相同的实例。

    public class MainActivity extends AppCompatActivity implements MainView {
    
        // 懒加载
        @Inject
        Lazy<MainPresenter> mPresenter;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            MainPresenterComponent component = DaggerMainPresenterComponent.builder()
                                                                           .mainPresenterModule(new MainPresenterModule(this))
                                                                           .applicationComponent(((DemoApplication) getApplication()).getAppComponent())
                                                                           .build();
            component.inject(this);
            Log.d("Hans", mPresenter.get().toString()); // 实例化MainPresenter
            Log.d("Hans", mPresenter.get().toString()); // 跟上次获取的实例是同一个实例
        }
    }
    

    Provider注入

    跟Lazy注入不一样的是,有时候我们希望每次调用get的时候,获取到的实例都是不一样的,这时候可以用Provider注入

    public class MainActivity extends AppCompatActivity implements MainView {
    
        // Provider
        @Inject
        Provider<MainPresenter> mPresenter;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
    
            MainPresenterComponent component = DaggerMainPresenterComponent.builder()
                                                                           .mainPresenterModule(new MainPresenterModule(this))
                                                                           .applicationComponent(((DemoApplication) getApplication()).getAppComponent())
                                                                           .build();
            component.inject(this);
            Log.d("Hans", mPresenter.get().toString()); // 实例化MainPresenter
            Log.d("Hans", mPresenter.get().toString()); // 获取新的MainPresenter实例
        }
    }
    

    Qualifiers注入

    到目前为止,我们的demo里,Moduld的provide返回的对象都是不一样的,但是下面这种情况就不好处理了:

    @Module
    public class ApplicationModule {
    
        ......
        
        // 返回ServerApi实例
        @Provides
        ServerApi provideServerApiA(Context context) {
            return new ServerApiImplA(context);
        }
    
        // 返回ServerApi实例
        @Provides
        ServerApi provideServerApiB(Context context) {
            return new ServerApiImplB(context);
        }
    }
    

    provideServerApiA和provideServerApiB返回的都是ServerApi,Dagger是无法判断用哪个provide方法的。这时候就需要添加Qualifiers了:

    @Module
    public class ApplicationModule {
    
        ......
    
        @Provides
        @Named("ServerApiImplA")
        ServerApi provideServerApiA(Context context) {
            return new ServerApiImplA(context);
        }
    
        @Provides
        @Named("ServerApiImplB")
        ServerApi provideServerApiB(Context context) {
            return new ServerApiImplB(context);
        }
    }
    

    通过这样一个限定,就能区分出2个方法的区别了,当然,在使用过程中,也同样要指明你用哪个name的实例,Dagger会根据你的name来选取对应的provide方法:

    public class MainPresenter {
    
        private MainView  mMainView;
        private ServerApi mServerApi;
    
        @Inject
        public MainPresenter(MainView mainView, @Named("ServerApiImplA") ServerApi serverApi) {
            this.mMainView = mainView;
            this.mServerApi = serverApi;
        }
    }
    

    除了用Named注解,你也可以创建你自己的限定注解:

    @Qualifier
    @Documented
    @Retention(RUNTIME)
    public @interface YourQualifier {
        String value() default "";
    }
    

    编译时验证

    Dagger 包含了一个注解处理器(annotation processor)来验证模块和注入。这个过程很严格而且会抛出错误,当有非法绑定或绑定不成功时。下面这个例子缺少了 Executor:

    @Module
    class DripCoffeeModule {
        @Provides Heater provideHeater(Executor executor) {
            return new CpuHeater(executor);
        }
    }
    

    当编译时,javac 会拒绝绑定缺少的部分:

    [ERROR] COMPILATION ERROR :
    [ERROR] error: java.util.concurrent.Executor cannot be provided without an @Provides-annotated method.
    

    可以通过给方法 Executor 添加@Provides注解来解决这个问题,或者标记这个模块是不完整的。不完整的模块允许缺少依赖关系

    @Module(complete = false)
    class DripCoffeeModule {
        @Provides Heater provideHeater(Executor executor) {
            return new CpuHeater(executor);
        }
    }
    

    小结

    第一次接触用Dagger框架写的代码时候,如果不了解各种注解作用的时候,那真会有一脸懵逼的感觉,而且单看文章,其实还是很抽象,建议大家用Dagger写个小demo玩玩,很快就上手了,这里提供几个使用Dagger的栗子,希望可以帮助大家上手Dagger

    相关文章

      网友评论

          本文标题:依赖注入利器 - Dagger ‡

          本文链接:https://www.haomeiwen.com/subject/pirhictx.html