对依赖注入，编译期注解，dagger2的认识理解

本文主要谈一下对依赖注入，编译期注解，dagger2的认识理解，不涉及代码分析，源码分析。分享给入门的同学，帮助更好的理解。
首先是依赖注入，依赖呢，就是一个类对另一个类产生依赖。比如在一个Class A里面用到了一个B类型的字段，那么就说Class A对Class B产生了依赖。B肯定是要进行初始化的（因为它是A中的属性字段，不初始化，就没啥用了。。），如果在A中直接new B（）；也就是把B的初始化硬编码到A里面，会带来一些问题，比如当B的构造参数变为B（String str）时，A里面就要做相应的改变new B（“啦啦啦”）；我们会发现A和B这样耦合程度太高了，一个改变，另一个就也要改变。如果解耦呢，那就用到注入了。
最常见的注入方式，就是传参，比如在Class A的构造器里，直接传一个B的对象进去。这样就解耦了。B不管怎么变，Class A的代码不会改动。但是，问题来了，那B在哪生成呢？怎么生成呀？
首先说在哪生成，不在A中生成，肯定是在第三方的类里生成。就是在A和B直接架一个C的桥梁。这样就会有疑问了，那B和C不就耦合了吗？因为，解耦并不是任何类之间完全失去联系（都不联系了，还怎么愉快的玩耍呢），而是把类之间的联系降到最低。现在就是要选择B和众多使用它的类联系呢，还是B只跟C联系，C跟众多使用B的类们联系。这样说，好像意义不大，但是可以再想一下，如果C是提供一个接口给A们，并且C里面管理很多需要注入的类，这样似乎就有意义了。

1539307788(1).png

其次怎么生成B呢，可以用反射，可以直接new，也可以用编译期注解，交给框架（也就是注解处理器处理）。其中，反射对性能有一点小小的影响，直接new呢，我们自己就要写很多代码，每一个需要注入的对象，都要去第三方的类中配置new 某某（），维护麻烦。所以这种麻烦的过程，不如交给已有的框架，这些框架其实是利用编译期注解处理器，帮我们生成那些代码。
再简单点来说，比如，以前我们在activity中需要写一大堆的findViewById（），写的手酸，后来呢，ButterKnife解救了我们，它利用注解，帮我们在编译期，生成一堆代码，这些代码就包含findViewById(),我们后面只需要调用它生成好的代码，就完成注入了，如下面草图，里面代码只是示意，不是真的：

1539307609(1).png

一直提编译期注解，下面就来讲一下它。理解它，你也可以利用编译期注解实现一个解耦框架。像ButterKnife，Dagger2等都是用编译期注解来实现的。具体的实现过程，需要三个必备因素：1.定义自己的注解（等于告诉用户，我这个框架解析的就是我定义的这些注解，你用了，我就可以解析到哦）；2.定义api接口（框架说白了，就是帮用户事先写好一大堆的代码，供用户直接调用，说到调用，当然要提供一个接口给用户。反过来说，只要用户写了这个符合规定的接口，那框架就负责实现这个接口的实现类，然后用户就可以直接调用实现类里面的代码啦）；3.实现注解处理器（这一步是关键，前面的注解和接口只是基本的配置，真正生成代码的工作是在注解处理器里完成的。注解处理器其实也就是实现一个Processor接口，实现里面几个方法就ok了。里面最主要实现的方法是process方法，通过它的参数RoundEnvironment获取到包含注解的类信息，然后遍历存储，最后拼成代码字符串，生成Javacode，存储成Java文件，跟我们自己写的Java文件没什么两样，一同编译，使用就可以了）。

1539308691(1).png

框架是怎么实现的，我们现在大概了解了，那接下来就看一下dagger2的一些知识点。dagger2是利用编译期注解的框架，自然它里面定义了一些注解供用户使用，如下图，上面蓝色的两个是dagger2自己定义的，下面红色的三个是Java本身就有的。

1539308896(1).png

下面是我对网上优秀的dagger2解析，做一个总结，拿来主义，大家也可以搜原博看看

1539309087(1).png

1539309144(1).png

1539309171(1).png

1539309243(1).png

这里要特别说明两个地方：一是Component就等于前面讲编译期注解需要定义api接口的那个api接口，用户定义不同的Component，dagger2就根据@Component注解找到并生成不同的辅助类，类名通常就是Dagger+你的Component名字；然后我们就可以直接使用Dagger+你的component名字里面的代码。Component在找有@inject标注的需要注入的对象时，是有优先级的，先找Component里设置的Moudle里是否提供了方法，如果没有再去看这个类的构造器是否被@Inject标注了，同理如果构造方法里有参数，参数也是按这个路线去找的。
二是关于@Scope这个，它修饰的是注解，有一个定义好的注解是@Singleton，标注这个@Singleton只是说明我需要把这个实例缓存到当前的类（比如Application，Activity等，取决于你Component.inject(this),这个this是谁，也就是inject的位置）。所以单纯标注一个@Singleton并不一定是单例，因为如果你Component.inject(某个activity中)，那对象只是缓存在此Activity的辅助类里而已，跟Activity同生命周期。所以要保证单例，必须是在Application中inject，同时用@Singleton标注。其他的作用域可以自己随便定义，起的就是一个限制作用。

附一个demo，重点看一下注入对象，@Singleton，@Qualifier的应用就行
https://github.com/mengwuwu/IOC_Dagger2.git

附一些博文连接供参考：
https://www.jianshu.com/p/cd2c1c9f68d4
https://blog.csdn.net/u011315960/article/details/64439575
https://blog.csdn.net/u012926924/article/details/52056180
https://blog.csdn.net/qfanmingyiq/article/details/75432854