上一片文章最后提到的容易让人误解的@Singleton希望大家要记住。 等等，说起来好像上上上篇文章里还有一个抬杠还没解决啊。就是如果在Module里两个Provider返回的类型是相同的，Dagger怎么知道使用哪个Provider提供的依赖注入呢？而且如果你真的在Module的两个Provdier中返回相同的类型，在编译时是会报错的！因为Dagger也不知道使用哪个，只好报错：你TM想要我用哪个？说清楚！
这时就会引出另外两个注解啦—Qualifier和Named！
举个常见的例子，就是通过Dagger提供Context。除了Application可以提供Context外，Activity也可以提供Context。代码如下：
image.png
还记得
@Module、
@Provides、
@GithubApplicationScope是什么意思吗？不记得可以回去翻翻上面的文章哦。
问题来了，如果把ActivityModule和ContextModule放到一起，Dagger在编译的时候就会因为不知道要用哪个Context报错。那么怎么解决这个问题呢？有两种方法：
-
@Named直接贴代码：
image.png
@Named后面的activity_context就是在告诉Dagger，这是一个叫activity_context的Context。
在要使用的context前面加上相同的注解即可，这样Dagger就知道具体使用的是哪个Context了。编译时就能 正常通过了。
image.png
大家发现没有，这样把字符串加来加去不仅麻烦还容易出错。那有没有其他方法呢？来，看下面一条。
-
@Qualifier
在看@Qualifier之前让我们先看看@Named的源码：
image.png
咦？这个@Named不就是一个@Qualifier嘛！那自己自定义一个专用@Qualifier得了。代码如下：
image.png
这样就不需要把字符串拷来拷去了，而且方便阅读和理解代码。具体的用法见下面代码：
image.png
image.png
好了，抬杠圆满结束。让我们开始下面的内容！
相关文章：
从实例出发理解Dagger2（一）
从实例出发理解Dagger2（二）
从实例出发理解Dagger2（三）
从实例出发理解Dagger2（四）
从实例出发理解Dagger2（五）
从实例出发理解Dagger2（六）
从实例出发理解Dagger2（七）
参考资料：https://www.youtube.com/watch?v=WAENNp2wxbQ&index=5&list=PLuR1PJnGR-Ih-HXnGSpnqjdhdvqcwhfFU
