Hilt 其实就是 dagger，它接管了对象的创建，并没有赋予对象生命周期。按照 Hilt 的使用方式，我们使用 Hilt 提供的各种注解对 Application、Activity、成员变量等进行注解后，就可以立即调用这些变量，而无需关心他们是怎样创建的了。那么这些变量是在什么时候，如何被创建的呢？通过一个简单的例子，根据 Hilt 生成的模板代码来分析其大概的实现原理。

结论

结论先行，以对框架原理有个整体的概念：

1、Hilt 会修改源码，但是改动点极少，只会修改源码中类的父类类型，它会为被注解的 XX 类创建一个 Hilt_XX 类，插入到 XX 的继承关系中，作为其父类。

2、在 Hilt_XX 类的 onCreate 之类的方法中提供了变量初始化的入口，所有被注解的变量从这里开始一层一层被全部实例化的。

3、组件的生命周期管理是通过 ViewModel 来实现的。

对源码的修改示例：

package com.hdf.hilt.ui

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

/**
 * Created by xiaxiao on 2021/11/16.
 *
 */
@HiltAndroidApp
class MyApplication : Application() {
}

最终 MyApplication.kt 文件对应的 MyApplication.class 文件中的源码会被修改为：

package com.hdf.hilt.ui

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

/**
 * Created by xiaxiao on 2021/11/16.
 *
 */
@HiltAndroidApp
class MyApplication : Hilt_MyApplication() {
}

而 Hilt_MyApplication 类则是 Hilt 生成的： class Hilt_MyApplication : Application() {}

修改发生在如下阶段：

1、Application 注解

@HiltAndroidApp
class MyApplication : Application() {
}

还是上面的示例代码，作为 app 的入口，也是 hilt 框架执行的入口，为 MyApplication 添加 @HiltAndroidApp 注解是必须的。加完注解后 build 一下，会发现生成了很多文件：

@HiltAndroidApp 注解生成的文件

Hilt_MyApplication：

如结论中所说，即是生成的一个新的父类，Hilt 是通过这种方式将它的工作插入到了正常的源代码逻辑中的。

public abstract class Hilt_MyApplication extends Application implements GeneratedComponentManager<Object> {
  private final ApplicationComponentManager componentManager = new ApplicationComponentManager(new ComponentSupplier() {
    @Override
    public Object get() {
      return DaggerMyApplication_HiltComponents_ApplicationC.builder()
          .applicationContextModule(new ApplicationContextModule(Hilt_MyApplication.this))
          .build();
    }
  });

  protected final ApplicationComponentManager componentManager() {
    return componentManager;
  }

  @Override
  public final Object generatedComponent() {
    return componentManager().generatedComponent();
  }

  @CallSuper
  @Override
  public void onCreate() {
    // This is a known unsafe cast, but is safe in the only correct use case:
    // MyApplication extends Hilt_MyApplication
    ((MyApplication_GeneratedInjector) generatedComponent()).injectMyApplication(UnsafeCasts.<MyApplication>unsafeCast(this));
    super.onCreate();
  }
}

在 onCreate 方法中插入的这行便是 hilt 的入口：

((MyApplication_GeneratedInjector) generatedComponent()).injectMyApplication(UnsafeCasts.unsafeCast(this));

代码后面有一个类型转换，把 this 转换成了源代码 MyApplication，其实从上面的注释中也可以看出来，MyApplication 实际上继承了 Hilt_MyApplication。

MyApplication_GeneratedInjector

从名字上看是一个 injector，因为现在对 MyApplication 进行了注解，所以这个类是负责注入 Application 的。

@OriginatingElement(
    topLevelClass = MyApplication.class
)
@GeneratedEntryPoint
@InstallIn(ApplicationComponent.class)
@Generated("dagger.hilt.android.processor.internal.androidentrypoint.InjectorEntryPointGenerator")
public interface MyApplication_GeneratedInjector {
  void injectMyApplication(MyApplication myApplication);
}

同样，它也是作为一个接口，定义了行为，具体的实现需要在他处实例化。

MyApplication_HiltComponents

无实际逻辑，但是它是最重要的，因为这里面定义好了所有组件的行为，Hilt 在这个 java 文件中声明了很多抽象类和接口，此后各种注解的工作都要依据这些接口或抽象类声明好的行为进行。

这里面声明了各种 XXC 抽象类就是以后被注解的 Activity、Fragment、Application 等要用到的

比如 ActivityC 现在只是个空实现

再来看一下 ApplicationC 类：

@Component(
    modules = {
        ApplicationContextModule.class,
        ActivityRetainedCBuilderModule.class,
        ServiceCBuilderModule.class
    }
)
@Singleton
public abstract static class ApplicationC implements MyApplication_GeneratedInjector,
    ApplicationComponent,
    HiltWrapper_ActivityRetainedComponentManager_LifecycleComponentBuilderEntryPoint,
    ServiceComponentManager.ServiceComponentBuilderEntryPoint,
    GeneratedComponent {
}

可以发现 ApplicationC 实现了 MyApplication_GeneratedInjector 接口，虽然它也是一个抽象类，但是这个实现标明之后 ApplicationC 的子类已经具有 MyApplication_GeneratedInjector 的功能。也就是说 MyApplication_GeneratedInjector 声明的 injectApplication 的功能肯定会在 ApplicationC 的子类中实现。

这里说这么多，是因为后面跟踪代码逻辑的时候会出现这些类之间的关系。

DaggerMyApplication_HiltComponents_ApplicationC

这个类的名字很长，其实他的类名表示此类是 MyApplication_HiltComponents.ApplicationC 的子类，即对 ApplicationC 抽象类的具体实现。

public final class DaggerMyApplication_HiltComponents_ApplicationC extends MyApplication_HiltComponents.ApplicationC {
  private DaggerMyApplication_HiltComponents_ApplicationC() {

  }

  public static Builder builder() {
    return new Builder();
  }

  public static MyApplication_HiltComponents.ApplicationC create() {
    return new Builder().build();
  }

  @Override
  public void injectMyApplication(MyApplication myApplication) {
  }

可以看到有了对 injectMyApplication 方法的实现，但是现在是个空实现。

到这，我们可以大概捋清楚当一个 Application 上增加了 @HiltAndroidApp 注解时，Hilt 做了哪些工作：

首先会创建一个包含很多接口和抽象类的 java 文件 MyApplication_HiltComponents，用来规范好所有的类关系和行为。

然后会为 Application 创建一个注射器 MyApplication_GeneratedInjector，负责将这个 Application 注入。

然后再创建一个 Application 的父类 Hilt_Application，用来替换掉源代码的继承关系，以此实现将 Hilt 插入到正常代码逻辑中，实现 Hilt 的功能。

最后，创建 DaggerMyApplication_HiltComponents_ApplicationC, 作为所有逻辑的具体实现。

代码的执行流程

现在为 MyApplication 添加一行代码

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        Log.i("xx", javaClass.superclass.name)
    }
}

断点发现 super.onCreate() 进入的是 Hilt_MyApplication 的 onCreate 方法

public void onCreate() {
  // This is a known unsafe cast, but is safe in the only correct use case:
  // MyApplication extends Hilt_MyApplication
  ((MyApplication_GeneratedInjector) generatedComponent()).injectMyApplication(UnsafeCasts.<MyApplication>unsafeCast(this));
  super.onCreate();
}

UnsafeCasts.unsafeCast(this)

这里的 this 其实就是 MyApplication ，所以虽然是不安全的类型转换，但是是没问题的。

generatedComponent 最终调用的是其成员变量 ApplicationComponentManager 类型的 componentManager 的 generatedComponent() 方法。这里用到了代理模式。

代理模式的应用：

public abstract class Hilt_MyApplication extends Application implements GeneratedComponentManager<Object> {
  private final ApplicationComponentManager componentManager = new ApplicationComponentManager(new ComponentSupplier() {
    @Override
    public Object get() {
      return DaggerMyApplication_HiltComponents_ApplicationC.builder()
          .applicationContextModule(new ApplicationContextModule(Hilt_MyApplication.this))
          .build();
    }
  });

  protected final ApplicationComponentManager componentManager() {
    return componentManager;
  }

  @Override
  public final Object generatedComponent() {
    return componentManager().generatedComponent();
  }

Hilt_MyApplication 实现了 GeneratedComponentManager 接口，而 ApplicationComponentManager 也实现了此接口。

实际调用的便是 ApplicationComponentManager.generatedComponent() ：

public final class ApplicationComponentManager implements GeneratedComponentManager<Object> {
  private volatile Object component;
  private final Object componentLock = new Object();
  private final ComponentSupplier componentCreator;

  public ApplicationComponentManager(ComponentSupplier componentCreator) {
    this.componentCreator = componentCreator;
  }

  @Override
  public Object generatedComponent() {
    if (component == null) {
      synchronized (componentLock) {
        if (component == null) {
          component = componentCreator.get();
        }
      }
    }
    return component;
  }
}

ApplicationComponentManager.generatedComponent() 在生成组件的时候使用双重检测的方式，而真正的 component 实例则是由一个组件提供者 ComponentSupplier 提供，这个ComponentSupplier 对象又是在创建组件管理器时传进来的：

public abstract class Hilt_MyApplication extends Application implements GeneratedComponentManager<Object> {
  private final ApplicationComponentManager componentManager = new ApplicationComponentManager(new ComponentSupplier() {
    @Override
    public Object get() {
      return DaggerMyApplication_HiltComponents_ApplicationC.builder()
          .applicationContextModule(new ApplicationContextModule(Hilt_MyApplication.this))
          .build();
    }
  });
  。。。。

所以这个组件便是一个 DaggerMyApplication_HiltComponents_ApplicationC 对象。

一路兜兜转转，Application 的注入操作

((MyApplication_GeneratedInjector) generatedComponent()).injectMyApplication(UnsafeCasts.<MyApplication>unsafeCast(this));

就是调用 DaggerMyApplication_HiltComponents_ApplicationC.injectMyApplication(MyApplication)

@Override
public void injectMyApplication(MyApplication myApplication) {
}

在目前的示例中，这个方法时空实现。

到此，便是 Hilt 入口的实现原理。

2、对象的创建流程

接下来，开始为示例中增加更多 Hilt 注解，以跟踪具体的对象创建流程。

增加两个普通类：医生 Doctor 和其所在的医院 Hospital

class Doctor {
    @Inject
    public Hospital hospital;
    
    @Inject
    public Doctor() {

    }
}

class Hospital {
    @Inject
    public Hospital() {
    }
}

增加一个 DoctorActivity:

@AndroidEntryPoint
public class DoctorActivity extends AppCompatActivity {

    @Inject
    public Doctor mDoctor;

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.i("xx", getClass().getSuperclass().getName());
        String s = mDoctor.hospital.toString();
        Log.i("xx", s);
    }
}

根据依赖注入框架的功能，通过以上这些注解，mDoctor 变量及其内部的 hospital 变量在调用的时候肯定是已经实例化的了。

build 一下，看一下生成的类：

Hospital 类相关的：

Hospital_Factory：负责提供 Hospital 实例，这个实例的来源就是 new Hospital()。而 Hospital_Factory 自身是一个通过内部类的形式实现的单例模式。不用使用同步锁就能保证一个单例。既可以延迟初始化，又能保证实例单一。

参考：深入理解单例模式：静态内部类单例原理_mnb65482的博客-CSDN博客_单例模式静态内部类

public final class Hospital_Factory implements Factory<Hospital> {
  @Override
  public Hospital get() {
    return newInstance();
  }

  public static Hospital_Factory create() {
    return InstanceHolder.INSTANCE;
  }

  public static Hospital newInstance() {
    return new Hospital();
  }

  private static final class InstanceHolder {
    private static final Hospital_Factory INSTANCE = new Hospital_Factory();
  }
}

Doctor 相关的类：

Doctor_Factory ：和 Hospital 的工厂类出现了区别，因为 Doctor 类中有 Hospital 类型的成员变量，所以 Doctor_Factory 对外提供一个 Doctor 实例的时候必须还要保证其中的成员变量也都实例化了，因此多了一个 hospitalProvider。另外 Doctor_Factory 没有做单例模式，因为要为 doctor.hospital 赋值，没法做了。

public final class Doctor_Factory implements Factory<Doctor> {
  private final Provider<Hospital> hospitalProvider;

  public Doctor_Factory(Provider<Hospital> hospitalProvider) {
    this.hospitalProvider = hospitalProvider;
  }

  @Override
  public Doctor get() {
    Doctor instance = newInstance();
    Doctor_MembersInjector.injectHospital(instance, hospitalProvider.get());
    return instance;
  }

  public static Doctor_Factory create(Provider<Hospital> hospitalProvider) {
    return new Doctor_Factory(hospitalProvider);
  }

  public static Doctor newInstance() {
    return new Doctor();
  }
}

Doctor_MembersInjector：负责把 Doctor 内的变量实例化的。

DoctorActivity 相关的：

Hilt_DoctorActivity：创建的新父类，用来插入初始化的逻辑

DoctorActivity_GeneratedInjector：用来注入 DoctorActivity 的

DoctorActivity_MembersInjector：用来实例化 DoctorActivity 中的变量的

对象初始化流程

所以当 DoctorActivity 启动的时候会先执行 super.onCreate() 方法

@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Log.i("xx", getClass().getSuperclass().getName());
    String s = mDoctor.toString();
    Log.i("xx", s);
}

进入 Hilt_DoctorActivity:

protected void onCreate(@Nullable Bundle savedInstanceState) {
  inject();
  super.onCreate(savedInstanceState);
}

一切真相都从 inject() 方法开始了。

注入操作和 Application 的很像

protected void inject() {
  ((DoctorActivity_GeneratedInjector) generatedComponent()).injectDoctorActivity(UnsafeCasts.<DoctorActivity>unsafeCast(this));
}

核心方法还是接口 DoctorActivity_GeneratedInjector 的 injectDoctorActivity()。关键在于找出真正的 DoctorActivity_GeneratedInjector 实例。

跟踪 generatedComponent()

@Override
public final Object generatedComponent() {
  return componentManager().generatedComponent();
}

protected ActivityComponentManager createComponentManager() {
  return new ActivityComponentManager(this);
}

protected final ActivityComponentManager componentManager() {
  if (componentManager == null) {
    synchronized (componentManagerLock) {
      if (componentManager == null) {
        componentManager = createComponentManager();
      }
    }
  }
  return componentManager;
}

Hilt_DoctorActivity 还是使用了代理模式，最终还是进入组件管理器 ActivityComponentManager 的方法：

@Override
public Object generatedComponent() {
  if (component == null) {
    synchronized (componentLock) {
      if (component == null) {
        component = createComponent();
      }
    }
  }
  return component;
}

protected Object createComponent() {
  if (!(activity.getApplication() instanceof GeneratedComponentManager)) {
    if (Application.class.equals(activity.getApplication().getClass())) {
      throw new IllegalStateException(
          "Hilt Activity must be attached to an @HiltAndroidApp Application. "
              + "Did you forget to specify your Application's class name in your manifest's "
              + "<application />'s android:name attribute?");
    }
    throw new IllegalStateException(
        "Hilt Activity must be attached to an @AndroidEntryPoint Application. Found: "
            + activity.getApplication().getClass());
  }

  return ((ActivityComponentBuilderEntryPoint)
          activityRetainedComponentManager.generatedComponent())
      .activityComponentBuilder()
      .activity(activity)
      .build();
}

重点在 activityRetainedComponentManager.generatedComponent() 这行。从这行开始，代码会饶了好大一个圈，回到 DaggerMyApplication_HiltComponents_ApplicationC 中。

首先， activityRetainedComponentManager.generatedComponent() 会进入到 ActivityRetainedComponentManager 的 createComponent() 方法：

private ActivityRetainedComponent createComponent() {
  return viewModelProvider.get(ActivityRetainedComponentViewModel.class).getComponent();
}

viewModelProvider 在 ActivityRetainedComponentManager 构造时被创建：

ActivityRetainedComponentManager(ComponentActivity activity) {
  this.viewModelProvider =
      new ViewModelProvider(
          activity,
          new ViewModelProvider.Factory() {
            @NonNull
            @Override
            @SuppressWarnings("unchecked")
            public <T extends ViewModel> T create(@NonNull Class<T> aClass) {
              ActivityRetainedComponent component =
                  ((GeneratedComponentManager<LifecycleComponentBuilderEntryPoint>)
                          activity.getApplication())
                      .generatedComponent()
                      .retainedComponentBuilder()
                      .build();
              return (T) new ActivityRetainedComponentViewModel(component);
            }
          });
}

这里传入了一个 ViewModelProvider.Factory 实例。

viewModelProvider.get(ActivityRetainedComponentViewModel.class) 方法最终又会调用到这里传进去的 Factory 对象的 create 方法，所以

return viewModelProvider.get(ActivityRetainedComponentViewModel.class).getComponent()；

这句最终返回的 component 就是 ViewModelProvider.Factory 的 create 方法中创建的 ActivityRetainedComponent component。

分析这段代码：

ActivityRetainedComponent component =
                  ((GeneratedComponentManager<LifecycleComponentBuilderEntryPoint>)
                          activity.getApplication())
                      .generatedComponent()
                      .retainedComponentBuilder()
                      .build();

activity.getApplication() 返回的是 MyApplication，因为他继承了 Hilt_MyApplication，所以这里可以转换成 (GeneratedComponentManager) 类型，所以接下来调用的 generatedComponent() 方法是调用的 Hilt_MyApplication 的 generatedComponent()：

@Override
public final Object generatedComponent() {
  return componentManager().generatedComponent();
}

最终返回的是一个 DaggerMyApplication_HiltComponents_ApplicationC 对象。接下来进入DaggerMyApplication_HiltComponents_ApplicationC 类了。

调用 retainedComponentBuilder()：

@Override
public ActivityRetainedComponentBuilder retainedComponentBuilder() {
  return new ActivityRetainedCBuilder();}

调用 ActivityRetainedCBuilder.build():

private final class ActivityRetainedCBuilder implements MyApplication_HiltComponents.ActivityRetainedC.Builder {
  @Override
  public MyApplication_HiltComponents.ActivityRetainedC build() {
    return new ActivityRetainedCImpl();
  }
}

返回了一个 ActivityRetainedCImpl 对象，这个对象最终在 ActivityRetainedComponentManager 类的

private ActivityRetainedComponent createComponent() {
  return viewModelProvider.get(ActivityRetainedComponentViewModel.class).getComponent();
}

中被返回，然后返回到 ActivityComponentManager 类的 createComponent() 方法中：

return ((ActivityComponentBuilderEntryPoint)
        activityRetainedComponentManager.generatedComponent())
    .activityComponentBuilder()
    .activity(activity)
    .build();

继续调用ActivityRetainedCImpl .activityComponentBuilder() 方法：

@Override
public ActivityComponentBuilder activityComponentBuilder() {
  return new ActivityCBuilder();}

继续调用 ActivityCBuilder.activity（activity).build()：

@Override
  public ActivityCBuilder activity(Activity activity) {
    this.activity = Preconditions.checkNotNull(activity);
    return this;
  }

  @Override
  public MyApplication_HiltComponents.ActivityC build() {
    Preconditions.checkBuilderRequirement(activity, Activity.class);
    return new ActivityCImpl(activity);
  }
}

返回的是一个 ActivityCImpl 对象。

饶了这么大一圈，Hilt_DoctorActivity 类的 inject 方法中：

protected void inject() {
  ((DoctorActivity_GeneratedInjector) generatedComponent()).injectDoctorActivity(UnsafeCasts.<DoctorActivity>unsafeCast(this));
}

这个 generatedComponent() 方法返回的是一个 DaggerMyApplication_HiltComponents_ApplicationC.ActivityRetainedCImpl.ActivityCImpl 类实例。

到此，逻辑才拨云见日，豁然开朗。

ActivityCImpl 开始真正执行对象创建

ActivityCImpl.injectDoctorActivity() 开始的代码就无比的清晰了:

@Override
public void injectDoctorActivity(DoctorActivity doctorActivity) {
  injectDoctorActivity2(doctorActivity);}
  
  private DoctorActivity injectDoctorActivity2(DoctorActivity instance) {
  DoctorActivity_MembersInjector.injectMDoctor(instance, getDoctor());
  return instance;
}

private Doctor getDoctor() {
  return injectDoctor(Doctor_Factory.newInstance());}

就是一步步的创建对象，为变量赋值了。

先后顺序就是先创建了 Doctor 实例，再创建 Hospital 实例，然后为 Doctor 的内部变量 hospital 赋值, 然后为 DoctorActivity 的 doctor 变量赋值。

所以，当我们在 DoctorActivity 的 onCreate 方法中调用 mDoctor 时，相关的一切都创建好了。

3、Activity 中的对象是如何被加入生命周期管理的

对象没有 Activity 类的生命周期！！！

这完全是个误解！！！

加入到生命周期管理的是 component 组件!

Hilt 会按照相应 Android 类的生命周期自动创建和销毁生成的组件类的实例。

Component 组件是如何被加入到生命周期管理的

首先，还是从入口处开始

((DoctorActivity_GeneratedInjector) generatedComponent()).injectDoctorActivity(UnsafeCasts.<DoctorActivity>unsafeCast(this));

这一行代码到底做了哪些工作

从 Hilt_DoctorActivity 的角度，缩减为：

new ActivityComponentManager(this).generatedComponent().injectDoctorActivity(this)

ActivityComponentManager: 用于管理 activity 中组件的创建的管理器。从这里开始要注意， activity 开始作为参数进行传参了，所以猜测 ActivityComponentManager 之后的代码中肯定会对 activity 进行声明周期上的处理。

new ActivityComponentManager(this)：

public ActivityComponentManager(Activity activity) {
  this.activity = activity;
  this.activityRetainedComponentManager =
      new ActivityRetainedComponentManager((ComponentActivity) activity);
}

ActivityComponentManager 对象持有了 activity ，并作为参数 new 出了一个 activityRetainedComponentManager 对象。

activityRetainedComponentManager 变量：

private final GeneratedComponentManager<ActivityRetainedComponent> activityRetainedComponentManager;

可以发现其实际类型 ActivityRetainedComponentManager 和ActivityComponentManager 一样，父类都是 GeneratedComponentManager ，即表示这个类就是用来创建一个组件的。不同之处在于 ActivityRetainedComponentManager 指定的组件类型是 ActivityRetainedComponent，而 ActivityRetainedComponent 则表明组件具有了生命周期。

继续往下跟进 new ActivityRetainedComponentManager((ComponentActivity) activity)：

ActivityRetainedComponentManager(ComponentActivity activity) {
  this.viewModelProvider =
      new ViewModelProvider(
          activity,
          new ViewModelProvider.Factory() {
            @NonNull
            @Override
            @SuppressWarnings("unchecked")
            public <T extends ViewModel> T create(@NonNull Class<T> aClass) {
              ActivityRetainedComponent component =
                  ((GeneratedComponentManager<LifecycleComponentBuilderEntryPoint>)
                          activity.getApplication())
                      .generatedComponent()
                      .retainedComponentBuilder()
                      .build();
              return (T) new ActivityRetainedComponentViewModel(component);
            }
          });
}

ActivityRetainedComponentManager 创建组件的工作全部由 viewModelProvider 提供，可以看到 activity 在此处参与了 viewModelProvider 对象的创建。

ViewModelProvider：为 scope 提供所需的 viewModel 的

private final Factory mFactory;//负责创建一个 viewModel
private final ViewModelStore mViewModelStore; //用来存储 viewModel 的


public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
    this(owner.getViewModelStore(), factory);
}
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
    mFactory = factory;
    mViewModelStore = store;
}

从构造方法中看， Activity 竟然也是一个 ViewModelStoreOwner 接口的实现类，

ViewModelProvider 的创建没有再进行过多的逻辑操作了，就是对自己的两个成员变量做了一下赋值操作，一个是拿到了 activity 中的 viewModel 存储器，另一个是依据 activity 创建了 viewModel 的工厂类。

各种创建工作到这就结束了，所以 Hilt_DoctorActivity 中的

protected void inject() {
  ((DoctorActivity_GeneratedInjector) generatedComponent()).injectDoctorActivity(UnsafeCasts.<DoctorActivity>unsafeCast(this));
}

generatedComponent() 的真正实现者就是一个 ViewModelProvider 。ViewModelProvider 会返回一个已存在的 viewModel 或者是创建一个新的 viewModel,新创建的 viewModel 会加入到 activity 的 viewmodelStore 中，和 activity 进行关联，因此，viewModel 便有了 activity 的声明周期。

ViewModel 的加入是为组件赋予生命周期的关键

/**
*/
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
    ViewModel viewModel = mViewModelStore.get(key);//从容器里查找已存在的

    if (modelClass.isInstance(viewModel)) {
        if (mFactory instanceof OnRequeryFactory) {
            ((OnRequeryFactory) mFactory).onRequery(viewModel);
        }
        return (T) viewModel;
    } else {
        //noinspection StatementWithEmptyBody
        if (viewModel != null) {
            // TODO: log a warning.
        }
    }
    if (mFactory instanceof KeyedFactory) {
        viewModel = ((KeyedFactory) mFactory).create(key, modelClass);
    } else {
        viewModel = mFactory.create(modelClass);//创建新的
    }
    mViewModelStore.put(key, viewModel);
    return (T) viewModel;
}

viewModel = mFactory.create(modelClass)则又回到了创建 viewModelProvider 时创建 factory 参数的地方：

ActivityRetainedComponentManager(ComponentActivity activity) {
  this.viewModelProvider =
      new ViewModelProvider(
          activity,
          new ViewModelProvider.Factory() {
            @NonNull
            @Override
            @SuppressWarnings("unchecked")
            public <T extends ViewModel> T create(@NonNull Class<T> aClass) {
              ActivityRetainedComponent component =
                  ((GeneratedComponentManager<LifecycleComponentBuilderEntryPoint>)
                          activity.getApplication())
                      .generatedComponent()
                      .retainedComponentBuilder()
                      .build();
              return (T) new ActivityRetainedComponentViewModel(component);
            }
          });
}

最终创建了一个 ActivityRetainedComponentViewModel 对象，作为 viewmodel，具有了生命周期，同时它持有了一个 component。而这里创建的这个 component 就是 Hilt_doctorActivity.inject() 方法中需要的那个 component。

创建 component 以及最后创建对象之所以看起来很复杂，感觉是因为到处都是在用代理模式。

简述依赖注入框架 Hilt 的实现原理

结论