Hilt原理分析二（HIlt如何实现Application的依赖注入）

系列文章

• Hilt原理分析一（Hilt技术概览）
• Hilt原理分析三（xxx_Factory的作用）

在上一篇文章中，我们知道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就实现了依赖注入，那么还用这个类干嘛呢？因为会在其他地方用到，欲知详情，请看下一篇文章。