1、简单的依赖注入实现方式
目标类 @Inject A a； 与目标类的实例A类的构造方法上@Inject A() {};如果该类的构造方法内涉及到其他类的实例 要保证该实例已被注入
2、复杂的依赖注入实现方式
例如第三方库，不可以直接在源代码的构造方法上添加@Inject注解，如何注入呢？Component注解可以帮我们完成这件事情，Component提供了建立桥梁的作用(Component必须是接口或抽象类且必须有@Component注解)，一端连着目标类，另一端连着Module类(由Component管理着)，Module类必须有@Mudule注解，如下：
注意：Component类里的inject方法并没有使用注解，该方法是用来依赖注入到一个类上，使其关联(形参放的是谁，该方法就写在哪个类中)，这里注入的是BaseActivity；Module里有一个构造方法，用于绑定全局的context，提供给该类内部使用，具体代码中如何处理的，如下
通过new ApplicationModule() 将全局的context传入
而这个getApplicationComponent方法实际上是在BaseActivity里面依赖注入的，在基类里注入方便其子类更方便的获取，如下
最后通过getApplicationComponent方法返回该ApplicationComponent实例对象，并在MainActivity类进行依赖注入
3、Activity注入
首先ActivityComponent依赖于ApplicationComponent(因为ApplicationComponent里注入了一些全局的实例)，Component提供一种方式依赖，书写方式如下
注：这里的构造方法，用于注入不同的activity，并提供返回当前activity实例的方法，调用者可以通过获取Component实例对象，调用getActivity()方法获取相应的activity, 所以该ActivityComponent更适合作为一个基类，只提供当前界面绑定的是哪一个activity方法即可，而让其子类去实现各个activity想要实现的具体方法，例如，MainActivity抽出一个叫UserComponent的子类来继承该基类，并拥有自己的提供的方法inject()用户绑定fragment，供调用者使用，还拥有父类共用的方法getActivity，用于绑定每一个具体的activity并返回，如下
实现类如下，注意该构造函数形参注释
这就是为什么形参内接口，都在ApplicationComponent里注入的原因，这样是不是也理解了UserModule里注入UseCase的原因了？可能其他地方构造函数用到了UseCase，接下来我们先绑定该UserComponent，在MainActivity类里，书写如下代码即可完成绑定
绑定了该UserComponent以后，那么问题来了，如何进行Fragment绑定呢？换句话讲，如何在Fragment里拿到该UserComponent对象呢？为了代码可扩展性，这里进行了封装，首先实现接口，该接口的泛型接收Component具体类型，具体如下
该接口的具体实现如下
实现了接口后，并重写该方法
重点来了，因为Fragment可以通过getActivity拿到当前activity实例的，所以在BaseFragment里是这样的
这样在该BaseFragment的子类里，就可以完成绑定啦
绑定的意义在哪里呢？ 绑定之后就可以拿到Module里定义的所有实例啦，而UserModule里只有一个实例方法，且并没有在UserComponent里对外提供，意味着我们不能使用，那么绑定的意义在哪里呢？首先我们先来回顾一下UserModule注入的实例对象
由于在UserComponent没有对外提供该对象的实例返回，但是注入了该fragment后，一定是完成了GetUserList类的注入，所以即使我们不能拿到该对象，也没关系。在UserListFragment里，有一个Presenter，用到了@Inject依赖注入
那么我们来看一下UserListPresenter类中的构造方法吧
看到这里大家应该明白了吧，该构造方法的形参用到了UseCase接口，而我们在绑定Fragment时已经注入了该接口的实现类GetUseList，So thats why... 这样我们就完成了对UserListPresenter的@Inject注入
