/ 今日科技快讯 /
近日，据外媒报道，苹果公司宣称其在全球已经有近100家零售店重新开业。该公司表示，它将严格限制入店顾客人数，给与每个人提供足够的空间，并重新将重点放在提供一对一的个性化服务上。所有员工和客户都将需要佩戴口罩，苹果将向没有自带口罩的客户提供防护设备。
/ 作者简介 /
本篇文章来自琼珶和予的投稿，分享了他对Jetpack中ViewModel源码的分析，相信会对大家有所帮助！同时也感谢作者贡献的精彩文章。
琼珶和予的博客地址：
https://www.jianshu.com/u/00b25c511dd3
/ 前言 /
最初，我认为ViewModel的原理是非常简单，包括网络上有很多相关的源码分析的文章都是这么认为。但是当我再一次认认真真的官方文档之后，才知道ViewModel涉及到的东西远不止我们所知道的那些。
众所周知，ViewModel保存的数据，在配置更改之后依然也是存在的。但是这就是引出了一个问题，ViewModel和onSaveIntanceState方法有什么区别？因为我们都知道onSaveIntanceState方法就是用来保存和恢复UI的状态和数据的。这个是本文分析的一个重点。
同时，ViewModel只会保存因为配置更改导致Activity重建相关的数据，并不能保存因为Activity退到后台，因资源限制(比如内存限制，电量限制等)导致被杀掉之前的数据--这就是onSaveIntanceState方法干的事。但是如果我们想要ViewModel能够拥有这部分的能力，又应该怎么办呢？这就设计到SavedStateHandle，这也是本文就要分析的一个重点。特别注意的是，我大概看了一下网络上相关的资料，发现在关于这部分的资料特别的少，大家似乎都不太重视这一块知识，但是我认为这一块的知识特别有必要介绍一下，所以本文会花费很多的笔墨分析它。
注意：本文ViewModel相关源码均是2.2.0版本。
/ 概述 /
按照老规矩，我们先来介绍我们对ViewModel已有的认识吧。在MVVM中，我们都知道ViewModel承担着一个重要角色--数据持有者。这个怎么来理解呢？我们用一个具体的场景来看看。
假设一个Activity界面有一个RecyclerView正在展示，同时RecyclerView的数据是从服务端请求过来的。当我们的手机第一次进入这个界面，手机是竖屏的，数据正常的请求，RecyclerView拿到数据也正常的展示。但是此时，如果我此时将手机横屏的话，会怎么样呢？会经历如下几个过程：
原来的Activity对象正常的走生命周期进行销毁。
新的Activity会被创建，同时生命周期也会走到onResume。
数据的恢复。如果我们没有使用ViewModel用来存储数据，那么就会重新从服务端请求数据；如果我们ViewModel来存储数据，则不会重新请求数据，而是将竖屏前数据保存，并且成功恢复到横屏的Activity上去。
我们可以用官方的一张图来简单的描述一下这个过程：
从这张图里面，我们可以看出，ViewModel的生命周期要比Activity长一点。因为配置更改导致的Activity销毁，ViewModel不会跟着销毁，只有Activity正常finish(比如用户点击back退出，或者退到后台杀掉App等)，ViewModel才会销毁。
上面说的都是大家都知道的知识，本文会从源码角度去分析为什么ViewModel能实现这种效果。
同时还会介绍SavedStateHandle，这个也在前面也说过了。因为我们都知道，ViewModel不能保存Activity被系统杀掉然后重建的数据，而借助SavedStateHandle,ViewModel便能解决这个问题。说句题外话，估计是Google看到大家怨声载道---为啥ViewModel只能保存配置更改的数据，才随便实现这个类来满足大家。正所谓大家苦ViewModel久矣。
/ 基本使用 /
在正式分析源码之前，我们先来看看ViewModel是怎么使用(虽然大家都比较熟悉)。首先，我们创建一个ViewModel子类，类里面有一个LiveData对象：
class MyViewModel : ViewModel() {
val mNameLiveData = MutableLiveData<String>()
}
然后我们在Activity里面使用它：
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val textView = findViewById<TextView>(R.id.textView)
val viewModel = ViewModelProvider(this)[MyViewModel::class.java]
viewModel.mNameLiveData.observe(this, Observer {
textView.text = it
})
}
}
我们的例子非常简单，这里就不过多的介绍。需要提一句的是，在最新的ViewModel中，以前通过ViewModelProviders.of方法来获取ViewModel已经过时了，现在我们是通过ViewModelProvider方法创建ViewModel对象。通常来说，我们还需要往ViewModelProider构造方法里面传递一个工厂类对象，如下：
ViewModelProvider(this, object : ViewModelProvider.Factory {
override fun <T : ViewModel> create(modelClass: Class<T>) =
MyViewModel() as T
})
当然，我们可以不带Factory对象。那么加入Factory对象之后，相比较于以前有什么好处呢？加了Factory之后，我们可以定义构造方法带参的ViewModel。比如说，如果，我们的一个ViewModel构造方法需要带一个id参数，那么我们可以在Factory的create方法里面创建对象直接带进去。
切忌，我们不要自己创建ViewModel对象，因为自己创建的对象不能保存因为配置更改导致Activity重建的数据，从而完美避开了ViewModel的优点。
针对于ViewModel的源码分析，本文从Factory这个切入点入手，逐步的分析ViewModel的创建和恢复。
/ ViewModel的创建 /
首先，我们先来看ViewModelProivder的构造方法。ViewModelProivder有很多构造方法，不过最终都调到同一个地方：
ViewModelProvider(this, object : ViewModelProvider.Factory {
override fun <T : ViewModel> create(modelClass: Class<T>) =
MyViewModel() as T
})
从这个方法中，我们看到两个变量，mFactory就是我们预期的工厂类，用来创建ViewModel对象；mViewModelStore是一个什么东西呢？这个很好理解，mViewModelStore就是用来存储的ViewModel对象的，比如同一个Activity的onCreate方法可能会多次回调，我们在onCreate方法初始化ViewModel的，但是不可能每次onCreate回调都会创建新的ViewModel对象，所以需要有一个东西用来存储的我们之前创建过的ViewModel，这个就是ViewModelStore的作用。同时在后面的内容，ViewModel生命周期比Activity的生命周期长也是因为这个类。
那么mViewModelStore对象是从哪里传过来，我们清楚的记得构造方法里面我们并没有传这个变量。
public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
this(owner.getViewModelStore(), factory);
}
我们可以看到从ViewModelStoreOwner获取的，那么那么些类是这个借口的实现类呢？从类图上来看，我们熟悉的ComponentActivity和Fragment实现了这个接口(这里我说的都是androidX包下)。这里，先不对ViewModelStoreOwner进行展开，后面在分析ViewModel的恢复会详细的讲解。
总之，上面两个变量都非常的重要。我们再来看一下get方法，因为真正获取ViewModel对象就是通过这个方法的。
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
String canonicalName = modelClass.getCanonicalName();
if (canonicalName == null) {
throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
}
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
这个get方法没有做什么事情，构造了一个默认的key，然后调用另一个get方法。我们来看看：
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;
}
这个get方法总的来说，主要分为以下2个过程：
先通过key从ViewModelStore(缓存)获取ViewModel对象，如果缓存中存在，直接返回。Activity经过横屏重建之后，返回ViewMode的对象l就是这里返回。如果缓存不存在，那么通过Factory创建一个对象，然后放在缓存中，最后返回。
默认的Facotry，我们这里不用过多的解释，就是简单的调用create方法创建ViewModel对象。那么那个OnRequeryFactory和KeyedFactory又是一个什么东西呢？KeyedFactory跟默认的Facotry比较，其实就是create方法多了一个参数，这个不用过多的纠结。
这里的核心是OnRequeryFactory，我们发现，当ViewModel是从ViewModelStore获取的，就是回调一次OnRequeryFactory的onRequery方法。这里回调onRequery方法有什么作用呢？这个设计到后面的SavedStateHandle，我们都知道当Activity因为资源限制被系统杀掉之后重新创建会恢复之前的状态，这里的onRequery方法的作用就是--为在这中情况能保存数据做做准备(往SavedStateRegistry里面注册SavedStateProvider)。那么可能有人就要问了ViewModel没有从缓存获取ViewModel，为啥不回调onRequery方法呢？我想说的是，注册最后都是要做的是，只是做工作可能不太一样，所以看不到onRequery方法的回调。这里，我先粗略描述一下，后面的内容会详细的分析这一块的内容，大家先对此有一个印象就行。
/ ViewModel的恢复 /
在前面的概述中，我们已经知道ViewModel的生命周期要比Activity长一点。那ViewModel是怎么做到的呢？对于这个问题，我猜大家首先想到的是缓存，并且这个缓存是被static关键字修饰的。正常来说，这个实现方案是没有问题的，我们也能找到具体的例子，比如Eventbus就是这么实现的。
那么在ViewModel中，这个是怎么实现的呢？我们都知道ViewModel是从一个ViewModelStore缓存里面的获取，我们看了ViewModelStore的源码，发现它的内部并没有通过静态缓存实现。那么它是怎么实现Activity在onDestroy之后(重建)，还继续保留已有的对象呢？
这个我们可以从ComponentActivity的getViewModelStore方法去寻找答案：
public ViewModelStore getViewModelStore() {
if (getApplication() == null) {
throw new IllegalStateException("Your activity is not yet attached to the "
+ "Application instance. You can't request ViewModel before onCreate call.");
}
if (mViewModelStore == null) {
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
// Restore the ViewModelStore from NonConfigurationInstances
mViewModelStore = nc.viewModelStore;
}
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
}
return mViewModelStore;
}
getViewModeStrore方法的目的很简单，就是获取一个ViewModelStrore对象。那么这个ViewModelStore可以从哪里获取呢？我们从上面的代码中可以找到两个地方：
从NonConfigurationInstances获取。
创建一个新的ViewModelStore对象。
第二点我们不用看，关键是NonConfigurationInstances。NonConfigurationInstances这是什么东西？这里，我简单解释一下NonConfigurationInstances：
NonConfigurationInstances其实就是一个Wrapper，用来包装一下因为不受配置更改影响的数据，包括我们非常熟悉的Fragment，比如说，一个Activity上面有一个Fragment，旋转了屏幕导致Activity重新创建，此时Activity跟之前的不是同一个对象，但是Fragment却是同一个。这就是通过NonConfigurationInstances实现的(有兴趣的同学可以了解一下Fragment这个case，还挺重要的，这里就不解释了。)。
上面说的内容看上去跟我们想要的效果挺像的。是的，ViewModelStore在Activity重建前后能保持同一个对象就是通过NonConfigurationInstances实现的。也就是说在getViewModelStore方法里面，从NonConfigurationInstances获取的ViewModelStore对象其实就是上一个Activity的。同时，我们还可以在ComponentActivity里面看到一段代码：
getLifecycle().addObserver(new LifecycleEventObserver() {
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
if (event == Lifecycle.Event.ON_DESTROY) {
if (!isChangingConfigurations()) {
getViewModelStore().clear();
}
}
}
});
从上面的代码中，我们可以到如果Activity是因为配置更改导致onDestroy方法的回调，并不会清空ViewModelStore里面的内容，这就能保证当Activity因为配置更改导致重建重新创建的ViewModel对象跟之前创建的对象是同一个。反之，如果Activity是正常销毁的话，则不会保存之前创建的ViewModel对象，对应的是ViewModelStore的clear方法调用。其实这个clear方法还跟kotlin里面的协程有关，这里就不过多解释了，有兴趣的同学可以看看ViewModel.viewModelScope。
现在我们来看一下NonConfigurationInstances为啥能保证Activity重建前后，ViewModeStore是同一个对象呢？主要满足大家的好奇心。
我们直接从ActivityThread的performDestroyActivity方法去寻找答案(是不是很慌)。我们知道，performDestroyActivity方法最后会回调到Activity的onDestroy方法，我们可以通过这个方法可以找到ActivtyThread在Activity onDestroy之前做了保存操作。
ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing,
int configChanges, boolean getNonConfigInstance, String reason) {
// ······
performPauseActivityIfNeeded(r, "destroy");
// Activity的onStop方法回调
if (!r.stopped) {
callActivityOnStop(r, false /* saveState */, "destroy");
}
if (getNonConfigInstance) {
// ······
// retainNonConfigurationInstances方法的作用就是创建一个对象
r.lastNonConfigurationInstances= r.activity.retainNonConfigurationInstances();
// ······
}
// ······
// Activity的onDestroy方法回调
mInstrumentation.callActivityOnDestroy(r.activity);
// ······
return r;
}
从上面的代码中，我们可以看到，在Activity的onStop和onDestroy之间，会回调retainNonConfigurationInstances方法，同时记录到ActivityClientRecord中去。这里retainNonConfigurationInstances方法返回的对象就是我们之前看到的NonConfigurationInstances对象。
那么又在哪里恢复已保存的NonConfigurationInstances对象呢？这个可以从performLaunchActivity方法找到答案。performLaunchActivity方法的作用就是启动一个Activity，Activity重建肯定会调用这个方法。在performLaunchActivity方法里面，调用了Activity的attach方法，在这个方法，Google将已有的NonConfigurationInstances赋值给了新的Activity对象。
到这里，我们就知道为啥NonConfigurationInstances能保证ViewModelStore在Activity重建前后是同一个对象，同时也知道为啥ViewModel的生命周期比Activity的生命周期要长一点。这里我先不总结，为了方便大家理解，最后我会统一的总结。
/ SavedStateHandle /
通过前面的内容，我们可以知道ViewModel保存和恢复的数据范围仅限于配置更改导致的重建，并不支持因为资源限制导致Activity重建(或许不应该称为重建？)的情况。但是，大家对此的呼声却从来没有停歇，Google因此新增了一个SavedStateHandle类，用来满足我们的要求。
在正式介绍SavedStateHandle之前，我们先看看onSaveInstanceState和ViewModel之间的区别。
onSaveInstanceState和ViewModel的区别
我们先来看看onSaveInstanceState:
onSaveInstanceState方法能保存的数据的场景：
由于资源限制，Activity被系统杀掉；
配置更改。
onSaveInstanceState方法只能保存少量简单的数据，大量和复杂数据最后不要放在onSaveInstanceState方法保存。因为onSaveInstanceState方法是通过Bundle保存数据，如果数据的量太大或者太复杂，会阻塞UI线程，从而影响Activity生命周期的执行。
我们再来看看ViewModel：
ViewModel能保存的数据的场景：配置更改。不支持由于限制导致Activity重建的场景。
ViewModel支持保存大量和复杂的数据，比如说RecyclerView的data。
从上面的内容，我们可以很明显的看出来各自的缺点和优点。既然Google爸爸在强力推荐View层和Model层分离的原则，那么ViewModel支持限制导致Activity重建的场景就显得尤为重要了。这不SavedStateHandle就出来了。
SavedStateHandle的基本使用
在分析SavedStateHandle源码之前，我们先来看看SavedStateHandle是怎么使用的吧。
首先定义一个构造方法带SavedStateHandle参数的ViewModel：
class MyViewModelWithSaveStateHandle(private val saveStateHandle: SavedStateHandle) : ViewModel() {
// 需要在资源限制导致重建的场景下保存的数据
// 用LiveData暴露，不能让外部直接通过LiveData去修改内部的值
val mAgeLiveData: LiveData<Int> = saveStateHandle.getLiveData(KEY_AGE)
// 普通的数据
val mNameLiveData = MutableLiveData<String>()
fun setAge(age: Int) {
saveStateHandle.set(KEY_AGE, age)
}
companion object {
const val KEY_AGE = "key_age";
}
}
其次，通过AbstractSavedStateViewModelFactory或者SavedStateViewModelFactory创建ViewModel对象:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val viewModel = ViewModelProvider(
this,
SavedStateViewModelFactory(application, this)
)[MyViewModelWithSaveStateHandle::class.java]
}
}
如果我们的ViewModel构造方法只带一个SavedStateHandle参数或者带有一个Application参数和SavedStateHandle参数，可以直接使用SavedStateViewModelFactory。如果构造方法还带有其他的参数，此时需要继承AbstractSavedStateViewModelFactory实现我们自己的工厂类。在使用AbstractSavedStateViewModelFactory时，我们需要注意一点：create方法带的SavedStateHandle参数一定传递到ViewModel里面去。
通过上面的2步，我们就可以在ViewModel保存由于资源限制导致重建的数据。是不是很简单呢？大家是不是如饥似渴的想要了解内部实现原理了呢？
现在我们准备分析它的内部实现原理，为啥说是准备呢？因为在正式看SavedStateHandle之前，我们先来看看几个东西，我们只有了解完这几个东西，分析SavedStateHandle才不会懵逼。
SavedState components
我们先来看一下SavedState components里面几个组件，分别是：SavedStateRegistryOwner，SavedStateRegistryController，SavedStateRegistry，SavedStateProvider。一下子怼上来4个不明所以的类，我猜测大家多多少少都有点懵逼。在这里我先分别这4个类的作用：
SavedStateRegistryOwner:一个接口，有一个getSavedStateRegistry方法，作用是提供SavedStateRegistry对象。该接口主要实现类有Activity和Fragment。
SavedStateRegistryController:SavedStateRegistry的控制类，主要有两个方法：performRestore方法的作用恢复数据；performSave方法主要保存数据。Activity和Fragment直接操作类就是该类。
SavedStateRegistry: 主要是从UI控制器(Activity或者Fragment等)恢复数据，或者需要保存的数据写入UI控制器的Bundle里面；外部可以通过registerSavedStateProvider方法注册SavedStateProvider，这样SavedStateRegistry在保存数据会SavedStateProvider提供的数据。SavedStateRegistryController主要操作类就是该类。
SavedStateProvider: 主要是提供保存和恢复的数据。该接口只有一个saveState方法，主要的作用将需要保存的数据用Bundle包装起来。
可以用一张图来描述他们之间的关系：
对这4个类有了大概的认识之后，我们就从源码的角度来看看这个4个类是怎么工作。首先我们来看看ComponentActivity：
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner,
ViewModelStoreOwner,
SavedStateRegistryOwner,
OnBackPressedDispatcherOwner {
private final SavedStateRegistryController mSavedStateRegistryController =
SavedStateRegistryController.create(this)；
// ······
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
// ······
}
@CallSuper
@Override
protected void onSaveInstanceState(@NonNull Bundle outState) {
// ······
mSavedStateRegistryController.performSave(outState);
}
// ······
}
我们从ComponentActivity源码可以看出来，SavedStateRegistryController主要分为两个过程：
在onCreate方法调用了performRestore方法，主要的作用是恢复已保存的数据。
在onDestroy方法调用了performSave方法，主要的作用保存数据。
因此，我们也分为两个过程来分析，分别从保存数据和恢复和数据来分析。
保存数据
SvedStateRegistryController的performSave方法做什么，只是调用了SavedStateRegistry的performSave方法。我们直接看SavedStateRegistry的performSave方法:
performSave方法里面主要做了三件事：
如果mRestoredState不为空，表示之前恢复的数据还没有被消费完，需要将没有消费的数据再一次保存。
遍历所有注册的SavedStateProvider，将所有的SavedStateProvider提供的数据保存起来。
将所有保存的数据全部写入到Activity的Bundle对象。注意：outBundle是Activity需要保存的数据Bundle。
保存的数据过程还是比较简单的，我们再来看看恢复数据的过程。
恢复数据
我们先来看看SvedStateRegistryController的performRestore方法：
public void performRestore(@Nullable Bundle savedState) {
Lifecycle lifecycle = mOwner.getLifecycle();
if (lifecycle.getCurrentState() != Lifecycle.State.INITIALIZED) {
throw new IllegalStateException("Restarter must be created only during "
+ "owner's initialization stage");
}
lifecycle.addObserver(new Recreator(mOwner));
mRegistry.performRestore(lifecycle, savedState);
}
相比于performSave方法，performRestore多了一些操作。但是我们不需要去关心，我们的重点还是应该放在SavedStateRegistry的performRestore方法：
void performRestore(@NonNull Lifecycle lifecycle, @Nullable Bundle savedState) {
if (mRestored) {
throw new IllegalStateException("SavedStateRegistry was already restored.");
}
if (savedState != null) {
mRestoredState = savedState.getBundle(SAVED_COMPONENTS_KEY);
}
lifecycle.addObserver(new GenericLifecycleObserver() {
@Override
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
if (event == Lifecycle.Event.ON_START) {
mAllowingSavingState = true;
} else if (event == Lifecycle.Event.ON_STOP) {
mAllowingSavingState = false;
}
}
});
mRestored = true;
}
SavedStateRegistry的performRestore方法做的操作从savedState获取之前保存的数据，然后赋值给mRestoredState。到这里，我们可能有疑问了？这里恢复数据只看到获取之前数据，但是没看到赋值到ViewModel。
其实SavedStateRegistry里面还有一个方法，我们一直没看--consumeRestoredStateForKey方法。我们来看看它的实现：
public Bundle consumeRestoredStateForKey(@NonNull String key) {
if (!mRestored) {
throw new IllegalStateException("You can consumeRestoredStateForKey "
+ "only after super.onCreate of corresponding component");
}
if (mRestoredState != null) {
Bundle result = mRestoredState.getBundle(key);
mRestoredState.remove(key);
if (mRestoredState.isEmpty()) {
mRestoredState = null;
}
return result;
}
return null;
}
consumeRestoredStateForKey方法的作用就是通过key从mRestoredState获取保存的数据。是不是看到一点苗头了？不错，外部类就是通过该方法来获取之前保存的数据。
SavedStateViewModelFactory
在看了4个类的实现之后，我们现在回过头来看看SavedStateViewModelFactory在创建ViewModel做了哪些操作。我们直接看create方法：
@NonNull
@Override
public <T extends ViewModel> T create(@NonNull String key, @NonNull Class<T> modelClass) {
boolean isAndroidViewModel = AndroidViewModel.class.isAssignableFrom(modelClass);
Constructor<T> constructor;
if (isAndroidViewModel) {
constructor = findMatchingConstructor(modelClass, ANDROID_VIEWMODEL_SIGNATURE);
} else {
constructor = findMatchingConstructor(modelClass, VIEWMODEL_SIGNATURE);
}
// doesn't need SavedStateHandle
if (constructor == null) {
return mFactory.create(modelClass);
}
SavedStateHandleController controller = SavedStateHandleController.create(
mSavedStateRegistry, mLifecycle, key, mDefaultArgs);
try {
T viewmodel;
if (isAndroidViewModel) {
viewmodel = constructor.newInstance(mApplication, controller.getHandle());
} else {
viewmodel = constructor.newInstance(controller.getHandle());
}
viewmodel.setTagIfAbsent(TAG_SAVED_STATE_HANDLE_CONTROLLER, controller);
return viewmodel;
} catch (IllegalAccessException e) {
throw new RuntimeException("Failed to access " + modelClass, e);
} catch (InstantiationException e) {
throw new RuntimeException("A " + modelClass + " cannot be instantiated.", e);
} catch (InvocationTargetException e) {
throw new RuntimeException("An exception happened in constructor of "
+ modelClass, e.getCause());
}
}
在create方法中，我们需要注意两点:
通过SavedStateHandleController的create方法创建了一个对象。在这个方法中，我们能找到很多的问题答案，比如说将已保存的数据恢复到SavedStateHandle、向SavedStateRegistry中注册SavedStateProivder以保证能成功保存数据。
通过反射创建ViewModel的对象。从这里，我们可以知道为啥SavedStateViewModelFactory的使用受限于ViewModel构造方法了。同时从反射中可以出来，将已有数据的SavedStateHandle传递到ViewModel。这就是能解释ViewModel为啥加一个参数，就是保存资源限制导致重建的数据的原因。
我们再来看看SavedStateHandleController的create方法：
create方法主要创建一个SavedStateHandleController对象，除了创建对象之外，还做了其他几件事：
调用consumeRestoredStateForKey方法，获取之前已保存的数据。并且将获取的数据创建一个SavedStateHandle,以供ViewModel使用。
调用attachToLifecycle。这里做的操作主要是将SavedStateHandle的SavedStateProvider注册到SavedStateRegistry里面，以保证以下保存数据的时机能成功SavedStateHandle所支持的数据。
到此，我们将SavedStateHandle里面一个数据者，它内部持有的数据主要是从保存和恢复的，这也是为啥ViewModel需要保存和恢复的数据要通过SavedStateHandle来初始化。
/ 总结 /
到此为止，ViewModel相关分析就结束了。在这里，我对本文做一个简单的总结。
ViewModel 和 onSaveInstaceState方法区别在于：ViewModel只能保存因为配置更改导致重建的数据，但是它能保存大量和复杂的数据；onSaveInstaceState能保存配置更改导致重建和资源限制导致重建的数据，但是它只能保存少量简单的数据。ViewModel使用SavedStateHandle能够保存资源限制导致重建的数据。
ViewModel的生命周期之所以比Activity的生命周期生命周期，主要重建之后的Activity用的是之前的ViewStore。ViewModelStore保存的是之前的ViewModel，而ViewStore在配置更改导致重建不会清空已有ViewModel。
推荐阅读：
欢迎关注我的公众号
学习技术或投稿
长按上图，识别图中二维码即可关注
572
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
