系列文章
在上一篇文章中，我们知道MyApplication添加了@HiltAndroidApp注解后，会生成四个文件
这节就来分析一下这四个文件，了解一下这四个文件的关系及作用，先从Hilt_MyApplication分析，代码如下
从Application的入口函数onCreate方法开始分析，可以看到代码很少，只有一句，Hilt_MyApplication类的其他方法也是被这句代码调用的，方法的调用顺序如下
在Hilt_MyApplication的componentManager方法中创建了ApplicationComponentManager对象，然后调用了ApplicationComponentManager对象的generatedComponent方法，代码如下
generatedComponent方法调用后，走到了这里
这里就走到了生成的4个类的另外一个类DaggerMyApplication_HiltComponents_SingletonC里面。
DaggerMyApplication_HiltComponents_SingletonC方法分析
调用的方法时序如下图
至此，Hilt_MyApplication的onCreate方法的
红框的部分就分析完了，红框部分执行后返回DaggerMyApplication_HiltComponents_SingletonC对象，然后injectMyApplication方法将Application作为入参传入，injectMyApplication方法的代码如下
这里只是一个空方法，看不出来什么，为了能更好的理解Hilt的原理，再在MyApplication类里面增加一些代码，如下
@HiltAndroidApp class MyApplication : Application() { @Inject lateinit var applicationModel: ApplicationModel override fun onCreate() { super.onCreate() applicationModel.doSomething() } }
ApplicationModel的代码如下
class ApplicationModel @Inject constructor() { fun doSomething() { Log.d("wizardev", "doSomething") } }
在MyApplication类中新增了成员变量并加了@Inject注解，然后在onCreate方法中直接调用doSometing方法，直接运行程序，打印的Log如下
可以发现，在MyApplication中并没有对applicationModel赋值，但是仍然可以直接调用doSometing方法，那么关于赋值的这部分毫无疑问是Hilt框架帮我们做的，Hilt是怎么做到的呢？仍然要从代码中获取答案。
Hilt是如何实现依赖注入的
直接看编译后代码的变化，如下图
可以看到编译后新增了两个类，从前文我们知道，MyApplication类没增加新增变量之前，DaggerMyApplication_HiltComponents_SingletonC的injectMyApplication方法是一个空方法，看下新增变量后的injectMyApplication方法，如下
再看下injectMyApplication2方法，如下
可以发现，最终调用到了新生成的MyApplication_MembersInjector类的injectApplicationModel方法，injectApplicationModel方法的代码如下
这个方法就是对MyApplication成员变量applicationModel赋值的地方，可以发现这里并没有用到另外一个类—ApplicationModel_Factory就实现了依赖注入，那么还用这个类干嘛呢？因为会在其他地方用到，欲知详情，请看下一篇文章。
