在开发过程中，为了实现解耦，我们经常使用依赖注入，常见的依赖注入方式有：
构造方法注入 ：在构造方法中把依赖作为参数传递进去setter方法注入 ：添加setter方法，把依赖传递进去接口注入 ：把注入方法抽到一个接口中，然后实现该接口，把依赖传递进去下面用一个小栗子来说明三种方式的用法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 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; } ... ... }
我们来看下使用一般的依赖注入方法时，代码会是怎么样的：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 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); } }
看起来还好是吧？但现实情况下，依赖情况往往是比较复杂的，比如很可能我们的依赖关系如下图：
PersonDaoImpl依赖类A，类A依赖B，B依赖C和D…在这种情况下，我们就要写出下面这样的代码了：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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会变成什么模样：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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需要做哪些？
分析生成依赖关系图，如PersonService–>PersonDaoImpl–>A–>B–>C&D 根据依赖关系图获取相关依赖，比如依次创建D、C、B、A、PersonDaoImpl、PersonService的实例 把生成的PersonService实例传递给MainActivity的mService成员变量 其实Dagger做的也就是上面这些事情了，接下来就让我们真正开始学习Dagger吧
首先我们应该用javax.inject.Inject去注解需要被自动注入的对象，@Inject是Java标准的依赖注入（JSR-330）注解。比如下面栗子中，需要注入的对象就是MainActivity的mService。这里有个要注意的地方，被@Inject注解的变量不能用private修饰
1 2 3 4 5 6 7 public class MainActivity extends AppCompatActivity // 注意，不能被private修饰 @Inject PersonService mService; ...... }
在执行依赖注入的时候，Dagger会查找@Inject注解的成员变量，并尝试获取该类的实例，Dagger最直接的方式就是直接new出相应的对象了。实例化对象的时候，会调用对象的构造方法，但假如有多个构造方法，具体用哪个构造方法来实例化对象？Dagger肯定是不会帮我们“擅自做主”的，用哪个构造方法来实例化对象应该是由我们做主的，所以我们需要给相应的构造方法添加@Inject注解 。
1 2 3 4 5 6 7 8 9 10 11 12 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里面会定义一些方法，这些方法会返回我们的依赖，就像：
1 2 3 4 5 6 7 8 9 10 11 @Module public class PersonServiceModule /** * 提供PersonDao接口实例 */ @Provides PersonDao providePersonDao (A a) { return new PersonDaoImpl(a); } }
Dagger根据需求获取一个实例的时候，并不总是通过new出来的，它会优先 查找Module
比如你用@Inject注解了一个成员变量，Dagger会查找Module中是否有用@Provides注解的，返回该类实例的方法，有的话就会调用provide方法来获得实例，然后注入，如果没有的话Dagger就会尝试new出一个实例。就像我们现在这个栗子，PersonService依赖于PersonDao接口，Dagger不能直接为我们new出一个接口，但我们可以提供一个Module，在Module中定义一个返回PersonDao接口实例的方法，这样，Dagger就可以解决实例化PersonDao的问题了。
我们再梳理一下流程，如果我们用@Inject注解了一个成员变量，并调用注入代码之后，Dagger会这样处理：
查找Module中是否有用@Provides注解的，返回该类实例的方法 如果有，就调用那个provide方法来获得实例，然后注入 如果没有，就尝试调用相应的类中被@Inject注解的构造方法new出一个实例，然后注入 如果没有一个构造方法被@Inject注解，Dagger会因不能满足依赖而出错 所以假如一个变量被@Inject注解，要么在Module中提供provide方法获取实例，要么该类提供一个被@Inject注解的构造方法，否则Dagger会出错
一般而言，Dagger会获取所有依赖的实例，比如当需要一个TestBean的时候，会通过new TestBean()创建实例并注入到类中。但是，以下情况会就不好处理了：
需要生成的是一个接口，而Dagger不能直接实例化接口 不能在第三方库的类中添加注解 可配置的对象必须是配置的 为了解决以上问题，我们需要定义一个被@Module注解的类，在里面定义用@Provides注解的方法。用该方法返回所需的实例。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 @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方法。
到目前为止，我们虽然知道了：
Dagger怎么获取实例：从Module的provide方法中获取 通过@Inject注解的构造方法new出新的实例 Dagger会推导provide方法和构造方法的参数，形成依赖图，并“满足”我们依赖图的需求，获取依赖的实例 看样子需要注入的依赖可以获取了，但是不是总觉得还有点“零碎”，整个流程还没连贯起来？比如，Module既然是一个类，生成依赖图的时候，怎么知道跟哪个Module挂钩？即使最后生成了需要的实例，注入的“目的地”是哪里？怎么才能把它注入到“目的地”？残缺的这部分功能，正是Component提供的，Component起到了一个桥梁的作用，贯通Module和注入目标。我们来看看最开始那个例子，我们是怎么进行依赖注入的：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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接口（这个接口是需要我们自己写的），我们来看下它实现的接口长什么样子：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 /** * 指定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其实也对应了一个依赖图 ，因为Component使用哪个Module是确定不变的，依赖关系无非也就是跟Module和类的定义有关。一旦这些都确定下来了，在这个Component范围内，依赖关系也就被确定下来了。额外再说一点，在Dagger1中，Component的功能是由ObjectGraph实现的，Component是用来代替它的。
Component定义好之后，build一下工程，Dagger就会自动为我们生成实现类了，就可以使用自动生成的实现类来进行依赖注入了。到现在为止，我们已经通过Dagger完成了依赖注入。可能看起来比正常方法麻烦得多，但是Dagger框架可以让依赖的注入和配置独立于组件之外，它帮助你专注在那些重要的功能类上。通过声明依赖关系和指定规则构建整个应用程序。
熟悉完Dagger基本的使用之后，接下来我们来讲解一些稍微高级一点的用法：
在Dagger中，Component之间可以有两种关系:Subcomponents和Component dependencies。他们有什么作用呢？比如在我们应用中，经常会有一些依赖我们在各个界面都使用得到，比如操作数据库、比如网络请求。假设我们有个ServerApi的接口，在页面A、B、C都使用到了，那么我们要在页面A、B、C的Component里面都能获取到ServerApi的实例，但显然，获取ServerApi实例的方法都是一样的，我们不想写重复的代码。于是我们可定义一个ApplicationComponent，在里面返回ServerApi实例，通过Component之间的关系便可以共享ApplicationComponent提供的依赖图。
下面通过Android中的一个小栗子来说明Subcomponents和Component dependencies如何使用
先说明下各个模块之间的关系
1 2 3 4 5 @Component (modules = ApplicationModule.class)public interface ApplicationComponent ServerApi getServerApi () ; }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 @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); } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 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对象
1 2 3 4 5 6 // 注意，这里有个dependencies声明 @Component (dependencies = ApplicationComponent.class, modules = MainPresenterModule.class)public interface MainPresenterComponent MainPresenter getMainPresenter () ; }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 @Module public class MainPresenterModule private MainView mMainView; public MainPresenterModule (MainView mainView) this .mMainView = mainView; } @Provides MainView provideMainView () { return mMainView; } }
1 2 3 4 5 6 7 8 9 10 11 public class MainPresenter private MainView mMainView; private ServerApi mServerApi; @Inject public MainPresenter (MainView mainView, ServerApi serverApi) this .mMainView = mainView; this .mServerApi = serverApi; } }
先抛开dependencies，我们分析这个这个依赖树是怎么样的
被依赖Component接口暴露的对象，可以添加到依赖者的依赖图中 Component接口没有暴露的对象，依赖者是不可见的 对于第一点应该比较好理解，就像这个栗子，MainPresenterComponent生成MainPresenter需要ServerApi，而ApplicationComponent中有接口暴露了ServerApi，所以MainPresenterComponent可以获得ServerApi
他们之间的关系可以用下图描述：
Subcomponents 实现方法一：
先定义子 Component，使 用@Subcomponent 标注（不可同时再使用 @Component） 父 Component 中定义获得子 Component 的方法 让我们对上面的栗子改造改造：
1 2 3 4 5 6 7 @Subcomponent (modules = MainPresenterModule.class)public interface MainPresenterComponent void inject (MainActivity activity) MainPresenter getMainPresenter () ; }
在ApplicationComponent中新增plus方法（名字可随意取），返回值为MainPresenterComponent，参数为MainPresenterModule：
1 2 3 4 5 @Component (modules = ApplicationModule.class)public interface ApplicationComponent MainPresenterComponent plus (MainPresenterModule module ) ; }
这样，就构建了一个ApplicationComponent的子图：MainPresenterComponent。子图和dependencies的区别就是，子图可以范围父图所有的依赖，也就是说，子图需要的依赖，不再需要在父Component中暴露任何对象，可以直接通过父图的Moduld提供！他们的关系变为了：
这里需要注意的是，以上代码直接在父 Component 返回子 Component 的形式，要求子 Component 依赖的 Module 必须包含一个无参构造函数，用以自动实例化。如果 Module 需要传递参数，则需要使用 @Subcomponent.builder 的方式，实现方法二实现步骤如下：
在子 Component，定义一个接口或抽象类（通常定义为 Builder），使用 @Subcomponent.Builder 标注编写返回值为 Builder，方法的参数为需要传入参数的 Module 编写返回值为当前子 Component的 无参方法 父 Component 中定义获得子 Component.Builder 的方法 代码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 @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();
在Dagger2中，一般都是使用@provide方法注入接口。在Android 中，一般我们会这样做，创建一个接口 Presenter 命名 为 HomePresenter
1 2 3 public interface HomePresenter Observable<List<User>> loadUsers() }
然后创建一个这个接口的实例：HomePresenterImp
1 2 3 4 5 6 7 8 public class HomePresenterImp implements HomePresenter public HomePresenterImp () } @Override public Observable<List<User>> loadUsers(){ //Return user list observable } }
然后在 Module 中，提供实例化的 provide 方法：
1 2 3 4 5 6 7 @Module public class HomeModule @Provides public HomePresenter providesHomePresenter () return new HomePresenterImp(); } }
但是，如果我们需要添加一个依赖到 presenter 叫 UserService，那就意味着，我们也要在 module 中添加一个 provide 方法提供这个 UserService，然后在 HomePresenterImp 类中加入一个 UserService 参数的构造方法。
1 2 3 4 5 6 7 @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可是非常的有用，Dagger2可以通过自定义注解限定注解作用域。@Singleton是被Dagger预先定义的作用域注解。
没有指定作用域的@Provides方法将会在每次注入的时候都创建新的对象 一个没有scope的component不可以依赖一个有scope的组件component 子组件和父组件的scope不能相同 Module中provide方法的scope需要与Component的scope一致 我们通常的ApplicationComponent都会使用Singleton注解，也就会是说我们如果自定义component必须有自己的scope。读者到这里，可能还不能理解Scopes的作用，我们先来看下默认提供的Singlton到底有什么作用，然后再讨论Scopes的意义：
Singletons是java提供的一个scope，我们来看看Singletons能做什么事情。
1 2 3 4 5 6 7 8 9 10 11 @Singleton public class ServerApi @Inject public ServerApi () } public boolean login (String username, String password) return "HansChen" .equals(username) && "123456" .equals(password); } }
方法二：用@Singleton注解Module的provide方法：
1 2 3 4 5 6 7 8 9 @Module public class ApplicationModule @Singleton @Provides ServerApi provideServerApi () { return new ServerApi(); } }
然后我们有个Component：
1 2 3 4 5 6 @Singleton @Component (modules = ApplicationModule.class)public interface ApplicationComponent ServerApi getServerApi () ; }
然后执行依赖注入：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 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的方法。
既然一个没有scope的component不可以依赖一个有scope的组件component，那么我们必然需要自定义scope来去注解自己的Component了，定义方法如下：
1 2 3 4 5 @Documented @Scope @Retention (RetentionPolicy.RUNTIME)public @interface FragmentScoped {}
定义出来的FragmentScoped在使用上和Singleton是一样的，那它和Singleton除了是不一样的注解之外，还有什么不一样呢？答案是没有！我们自定义的scope和Singleton并没有任何不一样，不会因为Singleton是java自带的注解就会有什么区别。
那么，这个scope的设定是为了什么呢？
scope除了修饰provide方法可以让我们获得在同一个Component实例范围内的单例之外，主要的作用就是对Component和Moduld的分层管理以及依赖逻辑的可读性。
ApplicationComponent一般会用singleton注解，相对的，它的Module中provide方法也只能用singleton注解。UserComponent是用UserSCope能直接使用ApplicationModule吗？不能！因为他俩的scope不一致，这就是这个设定带来的好处，防止不同层级的组件混乱。另外，因为有了scope的存在，各种组件的作用和生命周期也变得可读起来了
有时可能会需要延迟获取一个实例。对任何绑定的 T，可以构建一个 Lazy 来延迟实例化直至第一次调用 Lazy 的 get() 方法。注入之后，第一次get的时会实例化出 T，之后的调用都会获取相同的实例。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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()); // 跟上次获取的实例是同一个实例 } }
跟Lazy注入不一样的是，有时候我们希望每次调用get的时候，获取到的实例都是不一样的，这时候可以用Provider注入
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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实例 } }
到目前为止，我们的demo里，Moduld的provide返回的对象都是不一样的,但是下面这种情况就不好处理了：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @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了：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @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方法：
1 2 3 4 5 6 7 8 9 10 11 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注解，你也可以创建你自己的限定注解：
1 2 3 4 5 6 @Qualifier @Documented @Retention (RUNTIME)public @interface YourQualifier { String value () default "" ; }
Dagger 包含了一个注解处理器（annotation processor）来验证模块和注入。这个过程很严格而且会抛出错误，当有非法绑定或绑定不成功时。下面这个例子缺少了 Executor：
1 2 3 4 5 6 @Module class DripCoffeeModule @Provides Heater provideHeater (Executor executor) { return new CpuHeater(executor); } }
当编译时，javac 会拒绝绑定缺少的部分:
1 2 [ERROR] COMPILATION ERROR : [ERROR] error: java.util.concurrent.Executor cannot be provided without an @Provides-annotated method.
可以通过给方法 Executor 添加@Provides注解来解决这个问题，或者标记这个模块是不完整的。不完整的模块允许缺少依赖关系
1 2 3 4 5 6 @Module (complete = false )class DripCoffeeModule @Provides Heater provideHeater (Executor executor) { return new CpuHeater(executor); } }
第一次接触用Dagger框架写的代码时候，如果不了解各种注解作用的时候，那真会有一脸懵逼的感觉，而且单看文章，其实还是很抽象，建议大家用Dagger写个小demo玩玩，很快就上手了，这里提供几个使用Dagger的栗子，希望可以帮助大家上手Dagger
