目录
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 以及最后 创建对象之所以看起来很复杂,感觉是因为到处都是在用代理模式。