Hilt提供实例的来源-组件

  在前两章中，我们使用的对象实例都是Hilt帮我们注入的，众所周知java/kotlin是一门面向对象的语言，那么这些hilt帮我们传入的实例又是从哪里传入的呢。在Hilt的术语中，这些帮我们维护对象创建、注入、销毁的对象叫做：组件。

组件是 Hilt 生成的一个类，负责提供类型的实例，就像我们手动实现的容器一样。在编译期，Hilt 遍历依赖关系图，并生成代码，来提供所有类型并携带它们的传递依赖项。

  下面我们看一副Hilt的组件依赖图，它看起来很复杂但是别被它吓唬到了。

Hilt组件依赖图

  上面提到，组件是Hilt生成的一个类，负责提供实例，也就是说Hilt组件是类似一个“寄生虫”一样的东西，如果它依附的“寄主”死掉了，那么寄生虫也就死掉了，这样来看的话，被我们注入实例的那些Activity、Fragment、ViewModel就扮演了“寄主”的身份，上图中每一种组件都是表示了这个组件在寄主中的“寄生程度”。

  例如说SingetonComponent，从名字上我们就看出来他是一个单例组件，那么他是寄生在哪里的呢？毫无疑问是被我们打上了@HiltAndroidApp注解的那个Application（详情可看第一章），也就是说，SingetonComponent组件的生命周期实际上就是跟随Application，即贯穿整个程序生命周期（实质上的单例）。其他的组件的生命周期基本和他的名字保持一致，例如ActivityComponent与Activity，FragmentComponent和Fragment。特殊的是ActivityRetainedComponent和ActivityComponentd的区别，带retained的表示该组件不会随着Activity旋转销毁而销毁，而后者会每次Activity的销毁中都会重新生成组件，如果你的组件构建成本过大，建议使用带retained（笔者建议非特殊情况一律使用）。

  我们再继续看，依赖图中有很多指向下的线，表示上面的组件把他的依赖传递给了下面的组件，例如ServiceComponent可以获取在SingletonComponet中的实例，ViewComponent可以获取在ActivityComponent中的实例，当然也可以孙子获取爷爷的实例，全部组件都可以获取SingletonComponent的实例！相反的，更高级的组件是没办法获取低级组件的实例的，例如一个SingletonComponent是没办法获取ViewWithFragmentComponent中的实例。

Hilt组件提供实例的范围-作用域

  不同的Hilt组件仅仅表示他们依附的对象不同，并不会影响组件提供的实例，例如目前有一个SingletonComponent，他对外提供了Retrofit的实例，虽然组件本身是全局单例的，但是每一次尝试向这个组件申请retrofit对象实例的时候，组件都会提供不同的Retrofit实例！这显然是不符合我们需求的，我们需要向Hilt声明，全局只需要提供一个Retrofit实例，而这个声明在Hilt中被称为作用域。

作用域和组件的对应关系

  相同的，如果你希望在一个Activity中只需要同一个某个实例，那就可以使用ActivityReainedScoped，其他组件同理。

作用域实战

  假设我需要向整个项目提供提供一个单例的Room数据库，则可以使用以下的代码：

  上图中，因为MusicDatabase使用了Singleton注解，因此整个项目中无论哪里通过Hilt获取这个实例，都是访问的同一个实例，这就实现了单例。

  举一反三：如果我们把SingletonComponent换成ActivityRetainedComponent，把Singleton换成ActivityRetainedScoped，会变成什么样呢？答案是该实例只会在单个Activity中保持单例，不同的Activity中则会持有不同的实例，自己动手试试不同的组合带来的效果吧！

Hilt中优雅获取Context

  在讲作用域实战的那一段中，也许你注意到了代码中出现了@ApplicationContext这个注解，这正是Hilt提供的组件默认绑定，它可以让我们在Hilt中直接访问到项目的ApplicationContext而不用通过类似Application.getContext()的方式来硬编码获取。Hilt'为我们提供了两种默认绑定，分别是Activity的Context和Application的Context，他们的对应的注解分别是：@ActivityContext和@ApplicationContext。使用默认绑定我们可以写出以下的代码：

class AnalyticsAdapter @Inject constructor(
  @ActivityContext context: Context
) { //... }

class AnalyticsServiceImpl @Inject constructor(
  @ApplicationContext context: Context
) : AnalyticsService { //... }

进一步的来说，如果你单纯想获取Activity和Application而不是他们的Context，直接获取即可，因为Hilt已经默认帮我们绑定了。

class AnalyticsAdapter @Inject constructor(
  activity: FragmentActivity
) { //... }

class AnalyticsServiceImpl @Inject constructor(
  application: Application
) : AnalyticsService { //... }

总结

好的，这一章就到此结束了，目前而言都是构建的相对静态的对象，如果我们的对象的参数是动态的（例如网络请求返回），那我们该如何使用Hilt来构建对象呢；我们如何在Hilt不支持的类（例如在我们的工具类中）中注入我们需要的实例呢，下一章将为你解开。