深入AAC架构，彻底理解ViewModel的用法
/ 今日科技快讯 /
近日，谷歌宣布2020年投资计划，承诺将在加州、科罗拉多州、乔治亚州、马萨诸塞州、内布拉斯加州、纽约州、俄亥俄州、俄克拉荷马州、宾夕法尼亚州、德克萨斯州和华盛顿州等美国11个州投资“超过100亿美元”建设办公室和数据中心。
/ 作者简介 /
本篇文章来自七零八落问号的投稿，分享了ViewModel的使用以及相关的源码分析，相信会对大家有所帮助！同时也感谢作者贡献的精彩文章。
七零八落问号的博客地址：
https://www.jianshu.com/p/4a65ee05e6a1
/ ViewModel的主要工作 /
ViewModel本身主要是一个数据维护工具。
将数据维护的工作从Activity上剥离，提供一个储存数据环境，自身机制可以解决开发中，数据受Activity生命周期影响产生数据丢失的问题 (主要为横竖屏切换以及在后台被销毁)。
通常结合LiveData使用。
作为一个纯数据维护工具，可以加入到MVP架构中负责数据保存。而官方推选作为AAC架构MVVM中的VM层。
/ ViewModel的主要类 /
ViewModel (下称VM)
数据储存类，架构的核心类。使用时，直接继承该类，根据需求选择重写onCleared()方法。如需在Activity被系统销毁后依然保存数据，定义一个参数为(SavedStateHandle)的构造方法，并将数据保存SavedStateHandle中。实际上通过SavedInstanceState存取。
AndroidViewModel
VM子类，维护了Application的引用，由架构中的SavedStateViewModelFactory创建时传入。同样，需要接收SavedStateHandle时，需要定义参数为 (Application, SavedStateHandle)的构造方法。
ViewModelStore
用于保存VM，内部维护了一个用于储存VM的HashMap。一般情况下，直接使用本类创建实例。
ViewModelStoreOwner
接口，实现该接口的类，表示自身能够向外提供VM。androidx 的AppCompatActivity/Fragment实现了该接口。
ViewModelProvider
VM的提供者，获取VM的基本入口。实际依赖ViewModelStore存取VM，Factory生成/恢复VM。
Factory
接口，实现该接口的类主要用于创建VM实例。不建议直接实现该接口，除非你清楚框架内容和自己的需求。一般情况下，如果无需SavedStateHandle机制，可以使用AndroidViewModelFactory。否则应该使用或继承SavedStateViewModelFactory。
/ ViewModel的基本使用 /
一般使用。
// VM
class ViewModelA : ViewModel()
// AVM
class ViewModelB(app: Application) : AndroidViewModel(app)
// Activity/Fragment .onCreate中
override fun onCreate() {
...
val provider = ViewModelProvider(this)
val vmA = provider.get(ViewModelA::class.java)
val vmB = provider.get(ViewModelB::class.java)
...
}
接受SavedStateHandle。
// VM
class ViewModelC(
val handle: SavedStateHandle
) : ViewModel()
// AVM
class ViewModelD(
app: Application,
val handle: SavedStateHandle
) : AndroidViewModel(app)
跨Fragment共享数据
Fragment中直接以Activity作为ViewModel的Key。
...
val provider = ViewModelProvider(requireActivity())
val vmA = provider.get(ViewModelA::class.java)
通过Application创建全局共享的VM。
class App : Application(), ViewModelStoreOwner {
private lateinit var mAppViewModelStore: ViewModelStore
private lateinit var mFactory: ViewModelProvider.Factory
override fun onCreate() {
super.onCreate()
mAppViewModelStore = ViewModelStore()
mFactory = ViewModelProvider
.AndroidViewModelFactory
.getInstance(this)
}
override fun getViewModelStore(): ViewModelStore {
return mAppViewModelStore
}
private fun getAppFactory(): ViewModelProvider.Factory {
return mFactory
}
fun getAppViewModelProvider(activity: Activity): ViewModelProvider {
val app = checkApplication(activity) as App
return ViewModelProvider(app, app.getAppFactory())
}
fun getAppViewModelProvider(fragment: Fragment): ViewModelProvider {
return getAppViewModelProvider(fragment.requireActivity())
}
private fun checkApplication(activity: Activity): Application {
return activity.application
?: throw IllegalStateException(
"Your activity is not yet attached to the Application instance." +
"You can't request ViewModel before onCreate call.")
}
}
/ ViewModel关键源码分析 /
以下源码分析将会去除非相关代码以简化。
ViewModelProvider实现相关
前面提到，ViewModelProvider的工作完全依赖传入的ViewModelStore和Factory，可以直接从构造方法得知。
ViewModelProvider.java
----------------------
private final Factory mFactory;
private final ViewModelStore mViewModelStore;
public ViewModelProvider(ViewModelStoreOwner owner) {
this(owner.getViewModelStore(),
owner instanceof HasDefaultViewModelProviderFactory
? ((HasDefaultViewModelProviderFactory) owner)
.getDefaultViewModelProviderFactory()
: NewInstanceFactory.getInstance());
}
public ViewModelProvider(ViewModelStoreOwner owner, Factory factory) {
this(owner.getViewModelStore(), factory);
}
public ViewModelProvider(ViewModelStore store, Factory factory) {
mFactory = factory;
mViewModelStore = store;
}
// 简单的反射创建实例的工厂
public static class NewInstanceFactory implements Factory {
public T create(Class modelClass) {
return modelClass.newInstance()
}
}
而androidx.activity.ComponentActivity，androidx.fragment.app.Fragment都实现了ViewModelStoreOwner，HasDefaultViewModelProviderFactory接口。
public class AppCompatActivity extends FragmentActivity...{}
public class FragmentActivity extends ComponentActivity...{}
public class ComponentActivity extends ... implements
ViewModelStoreOwner,
HasDefaultViewModelProviderFactory,
SavedStateRegistryOwner ... {}
public class Fragment implements
ViewModelStoreOwner,
HasDefaultViewModelProviderFactory,
SavedStateRegistryOwner ... {}
ViewModelProvider的get()方法中返回VM实例，其中mFactory为SavedStateViewModelFactory。
ViewModelProvider.java
----------------------
private static final String DEFAULT_KEY
= "androidx.lifecycle.ViewModelProvider.DefaultKey";
public T get(@NonNull Class modelClass) {
String canonicalName = modelClass.getCanonicalName();
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
public T get(String key, Class modelClass) {
ViewModel viewModel = mViewModelStore.get(key);
// 一个确保机制
if (modelClass.isInstance(viewModel)) {
if (mFactory instanceof OnRequeryFactory) {
((OnRequeryFactory) mFactory).onRequery(viewModel);
}
return (T) viewModel;
}
// 正常以及基本的逻辑
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);
} else {
viewModel = (mFactory).create(modelClass);
}
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
SavedStateViewModelFactory在后面解析。
ViewModel 的屏幕横竖屏切换恢复机制
前面说到，创建VM是通过ViewModelProvider实现的，而ViewModelProvider又是依赖ViewModelStore进行VM的保存。当使用ComponentActivity/Fragment作为ViewModelProvider的初始化参数时，实际VM的储存容器是参数提供的。
ComponentActivity 实现
从源码中，可以看出横竖屏切换是直接通过NonConfigurationInstances进行恢复的。ComponentActivity包含一个NonConfigurationInstances类，其中持有ViewModelStore的引用。
ComponentActivity.java
----------------------
static final class NonConfigurationInstances {
Object custom;
ViewModelStore viewModelStore;
}
保存ViewModelStore
通过onRetainNonConfigurationInstance()在横竖屏切换中保存ViewModelStore。
ComponentActivity.java
----------------------
public final Object onRetainNonConfigurationInstance() {
Object custom = onRetainCustomNonConfigurationInstance();
// 从上一个 NonConfigurationInstances 中恢复 ViewModelStore
ViewModelStore viewModelStore = mViewModelStore;
if (viewModelStore == null) {
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
viewModelStore = nc.viewModelStore;
}
}
if (viewModelStore == null && custom == null) {
return null;
}
// 保存当前 ViewModelStore
NonConfigurationInstances nci = new NonConfigurationInstances();
nci.custom = custom;
nci.viewModelStore = viewModelStore;
return nci;
}
在使用时尝试通过getLastNonConfigurationInstance()恢复ViewModelStore。
ComponentActivity.java
----------------------
public ViewModelStore getViewModelStore() {
if (mViewModelStore == null) {
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
// 通过 NonConfigurationInstances 对象直接恢复 ViewModelStore
mViewModelStore = nc.viewModelStore;
}
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
}
return mViewModelStore;
}
Fragment 实现
Fragment的ViewModelStore由FragmentManager维护的FragmentManagerViewModel管理。注意这里使用了一个VM来维护一个ViewModelStore。
Fragment.java
-------------
public ViewModelStore getViewModelStore() {
return mFragmentManager.getViewModelStore(this);
}
FragmentManager.java
--------------------
private FragmentManagerViewModel mNonConfig;
ViewModelStore getViewModelStore(Fragment f) {
return mNonConfig.getViewModelStore(f);
}
处理FragmentManagerViewModel的实例化。
FragmentManager.java
--------------------
void attachController(FragmentHostCallback host,
FragmentContainer container,
final Fragment parent) {
mHost = host;
mParent = parent;
if (parent != null) {
// 从父类的FM中获取
mNonConfig = parent.mFragmentManager.getChildNonConfig(parent);
} else if (host instanceof ViewModelStoreOwner) {
// 假如 host 对象是实现了 ViewModelStoreOwner
// 则使用这个ViewModelStoreOwner的viewModelStore创建一个 FragmentManagerViewModel
ViewModelStore viewModelStore =
((ViewModelStoreOwner) host).getViewModelStore();
mNonConfig = FragmentManagerViewModel.getInstance(viewModelStore);
} else {
// 生成一个不支持自动保存ViewModel的 FragmentManagerViewModel
mNonConfig = new FragmentManagerViewModel(false);
}
}
但从源码注释可以了解到，第三种情况已废弃，理想情况下并不支持。
所以基本上，出现的应该为第一、第二种情况。host对象实际是实现的ViewModelStoreOwner接口的FragmentActivity$HostCallbacks：
FragmentActivity.java
---------------------
class HostCallbacks
extends FragmentHostCallback
implements ViewModelStoreOwner ... {...}
第二种情况，attachController()传入参数为null，可以理解为直接附着在FragmentActivity上的Fragment:
FragmentActivity.java
---------------------
protected void onCreate(@Nullable Bundle savedInstanceState) {
mFragments.attachHost(null /*parent*/);
}
FragmentController.java
-----------------------
public void attachHost(Fragment parent) {
mHost.mFragmentManager.attachController(mHost, mHost, parent);
}
而第一种情况，attachController()传入参数为Fragment，在Fragment的performAttach()中调用：
Fragment.java
-------------
void performAttach() {
mChildFragmentManager.attachController(mHost, new FragmentContainer(), this)
}
解决了FragmentManagerViewModel的来源，下面看看它的作用。上文提到，FragmentManagerViewModel是一个VM，实际上可以联想到可能是通过Activity的ViewModelStore，使用相同的NonConfigurationInstances机制实现的恢复。先看第二种情况：
FragmentManager.java
--------------------
ViewModelStore viewModelStore = ((ViewModelStoreOwner) host).getViewModelStore();
mNonConfig = FragmentManagerViewModel.getInstance(viewModelStore);
其中的host为FragmentActivity$HostCallbacks，而getViewModelStore()返回的实际上是FragmentActivity的ViewModelStore：
FragmentActivity$HostCallbacks.java
-----------------------------------
public ViewModelStore getViewModelStore() {
return FragmentActivity.this.getViewModelStore();
}
而FragmentManagerViewModel.getInstance()内部实际上是通过ViewModelProvider返回一个本类VM实例：
FragmentManagerViewModel .java
------------------------------
static FragmentManagerViewModel getInstance(ViewModelStore viewModelStore) {
ViewModelProvider viewModelProvider =
new ViewModelProvider(viewModelStore, FACTORY);
return viewModelProvider.get(FragmentManagerViewModel.class);
}
由于VM在创建时，会被储存到对应的ViewModelStore，所以该VM会存放到FragmentActivity的ViewModelStore中。
第一种情况：
实际上是顶级FragmentManager的FragmentManagerViewModel中，维护一个子级的FragmentManagerViewModel仓库，然后通过顶级FragmentManagerViewModel直接维护所有子级FragmentManagerViewModel。
FragmentManagerViewModel .java
------------------------------
private final HashMap mChildNonConfigs = new HashMap<>();
FragmentManagerViewModel getChildNonConfig(@NonNull Fragment f) {
FragmentManagerViewModel childNonConfig = mChildNonConfigs.get(f.mWho);
if (childNonConfig == null) {
childNonConfig = new FragmentManagerViewModel(mStateAutomaticallySaved);
mChildNonConfigs.put(f.mWho, childNonConfig);
}
return childNonConfig;
}
从以上源码中可以看出，Fragment的横竖屏切换恢复机制实际上是。通过一个持有自身ViewModelStore引用的VM，依附到Activity的ViewModelStore中，通过Activity的机制进行恢复。
其实这里引申一点的是，源码中提及到，NonConfigurationInstances机制有可能在调用getLastNonConfigurationInstance时返回null，如需确保横竖屏切换时的数据保存，可以使用Fragment的onSaveInstanceState(true)，以Fragment作为保存数据的容器。
而事实上，在旧版的ViewModel中，确实是通过Fragment的onSaveInstanceState(true)进行的。
ViewModel 的后台销毁恢复机制
前文提到，SavedStateViewModelFactory是实现该机制的一部分，由SavedStateViewModelFactory生成的VM才具有在后台销毁前后通过SavedStateHandle存取数据的特性。先看SavedStateViewModelFactory的构造方法。
SavedStateViewModelFactory.java
-------------------------------
public SavedStateViewModelFactory(Application application,
SavedStateRegistryOwner owner,
Bundle defaultArgs) {
mSavedStateRegistry = owner.getSavedStateRegistry();
mLifecycle = owner.getLifecycle();
mDefaultArgs = defaultArgs;
mApplication = application;
mFactory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
}
SavedStateViewModelFactory在ComponentActivity中实例化传入的参数。
ComponentActivity.java
----------------------
mDefaultFactory = new SavedStateViewModelFactory(
getApplication(),
this,
getIntent() != null ? getIntent().getExtras() : null);
ComponentActivity实现了SavedStateRegistryOwner接口，该接口的实现类可以提供SavedStateRegistry实例。SavedStateRegistry即是流程的关键对象之一。
这里涉及到androidx提供的一个新的组件androidx.savedstate："该组件允许以插件方式，将组件添加到SaveInstanceState过程中"。
个人理解
这是一套针对SavedState操作Bundle的封装工具，但仅适用于系统实现。
因为流程繁琐，系统源码在实现的过程中还包含了自动重建，自动还原数据，生命周期确保等一系列操作。而且当你实现关键的SavedStateProvider接口时，同样要编写Bundle，这和传统的onSaveInstanceState()区别不大。
因为系统实现了对VM提供的存取操作，建议直接使用VM，或者直接在onSaveInstanceState()对数据进行操作。ComponentActivity实例化时，创建成员SavedStateRegistryController，后者实例化时，创建成员SavedStateRegistry。
ComponentActivity.java
----------------------
private final SavedStateRegistryController mSavedStateRegistryController =
SavedStateRegistryController.create(this);
SavedStateRegistryController.java
---------------------------------
public static SavedStateRegistryController create(SavedStateRegistryOwner owner) {
return new SavedStateRegistryController(owner);
}
private SavedStateRegistryController(SavedStateRegistryOwner owner) {
mOwner = owner;
mRegistry = new SavedStateRegistry();
}
ComponentActivity在onSaveInstanceState()中调用SavedStateRegistryController.performSave()，内部实际调用SavedStateRegistry.performSave()。
ComponentActivity.java
----------------------
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
mSavedStateRegistryController.performSave(outState);
}
SavedStateRegistryController.java
---------------------------------
public void performSave(Bundle outBundle) {
mRegistry.performSave(outBundle);
}
SavedStateRegistry会把所有注册到自身的SavedStateProvider，通过saveState()提取数据，并保存到一个Bundle中。
SavedStateRegistry.java
-----------------------
void performSave(@NonNull Bundle outBundle) {
Bundle components = new Bundle();
for (Iterator> it =
mComponents.iteratorWithAdditions(); it.hasNext(); ) {
Map.Entry entry1 = it.next();
components.putBundle(entry1.getKey(), entry1.getValue().saveState());
}
outBundle.putBundle(SAVED_COMPONENTS_KEY, components);
}
至此，说明数据保存的发起，最终通知到SavedStateRegistry。
先看SavedStateProvider接口。注册到SavedStateRegistry中实现类，会在SavedStateRegistry保存过程将会调用saveState()获取数据。而稍后(在恢复数据时)，将会通过SavedStateRegistry.consumeRestoredStateForKey()取出保存的数据。
SavedStateProvider通过SavedStateRegistry.registerSavedStateProvider()注册到SavedStateRegistry。
SavedStateRegistry.java
-----------------------
public void registerSavedStateProvider(String key, SavedStateProvider provider) {
SavedStateProvider previous = mComponents.putIfAbsent(key, provider);
if (previous != null) {
throw new IllegalArgumentException(
"SavedStateProvider with the given key is already registered");
}
}
到此，说明储存数据的提供者，是注册到SavedStateRegistry中的SavedStateProvider。前文提及，VM的存取核心是SavedStateHandle，那么说明SavedStateProvider和SavedStateHandle存在必然的关联。
实际上，SavedStateHandle实例中，维护一个SavedStateProvider匿名内部类实例，而SavedStateHandle的读写和SavedStateProvider实例的数据读取操作，都是对实际数据容器mRegular读写。
前文提到，最终该机制的实现，实际为SaveInstanceState机制，则反映VM并不会对数据进行自动存取。事实上VM确实需要手动将后台销毁前保存的数据放到SaveInstanceState中，SavedStateHandle确实是这么用的，所以提供了一系列的get/set操作，而最终还要编写SavedStateProvider的Bundle转换操作。同时可以看出，SavedStateHandle提供了对LiveData的存取支持。
SavedStateHandle对LiveData的支持，来自对LiveData的内部的静态包装类SavingStateLiveData。SavingStateLiveData包装了setValue()，传入的参数会被优先储存到mRegular中。
用于提取数据的SavedStateProvider。需要编写SavedStateProvider数据的Bundle转换操作。所以如无必要，无需自定义该组件，建议在onSaveInstanceState()中直接操作。
SavedStateHandle.java
---------------------
// 最终的数据容器主体
// initialState为构造时参入的上次SavedInstanceState产生的旧数据
// 既 SavedStateHandle.createHandle 时传入的参数，下面会说明
final Map mRegular = new HashMap<>(initialState);
// SavedStateProvider 对数据主体 mRegular 进行处理并生成一个Bundle
private final SavedStateProvider mSavedStateProvider = new SavedStateProvider() {
public Bundle saveState() {
Set keySet = mRegular.keySet();
ArrayList keys = new ArrayList(keySet.size());
ArrayList value = new ArrayList(keys.size());
for (String key : keySet) {
keys.add(key);
value.add(mRegular.get(key));
}
Bundle res = new Bundle();
// "parcelable" arraylists - lol
res.putParcelableArrayList("keys", keys);
res.putParcelableArrayList("values", value);
return res;
}
};
至此，SavedStateHandle和SavedStateProvider实现关联。
前文提及，SavedStateProvider通过SavedStateRegistry.registerSavedStateProvider()注册到SavedStateRegistry。而该方法的调用，则是通过SavedStateHandleController进行的。SavedStateHandleController的实例化则是通过SavedStateViewModelFactory进行的，最终回到了SavedStateViewModelFactory。
先看SavedStateViewModelFactory，通过调用SavedStateHandleController.create()返回SavedStateHandleController实例。同时，VM在创建时，传入了SavedStateHandleController的SavedStateHandle实例作为参数，即VM和SavedStateHandle进行了绑定。
SavedStateViewModelFactory.java
-------------------------------
public T create(String key, Class modelClass) {
// 判断是否是AVM
boolean isAndroidViewModel = AndroidViewModel.class.isAssignableFrom(modelClass);
Constructor constructor;
if (isAndroidViewModel) {
constructor = findMatchingConstructor(modelClass, ANDROID_VIEWMODEL_SIGNATURE);
} else {
constructor = findMatchingConstructor(modelClass, VIEWMODEL_SIGNATURE);
}
// 如果不需要SavedStateHandle，则直接创建一个普通的VM/AVM
if (constructor == null) {
return mFactory.create(modelClass);
}
// 创建了 SavedStateHandleController
SavedStateHandleController controller = SavedStateHandleController.create(
mSavedStateRegistry, mLifecycle, key, mDefaultArgs);
// VM 在创建的时候持有了SavedStateHandleController内维护的SavedStateHandle对象
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;
...
}
再看SavedStateHandleController .create()：
SavedStateHandle在实例化时，通过consumeRestoredStateForKey()传入上次保存的数据，此时SavedStateHandle数据已完成恢复。
SavedStateHandleController创建后，通过attachToLifecycle()方法，在方法内部将SavedStateHandle维护的SavedStateProvider注册到SavedStateRegistry。
前面说到SavedStateViewModelFactory是框架骨架之一，实际就是通过这个过程，最终允许VM能够把数据的存取加入到SaveInstanceState流程。
SavedStateHandleController.java
-------------------------------
static SavedStateHandleController create(SavedStateRegistry registry,
Lifecycle lifecycle, String key, Bundle defaultArgs) {
// 通过consumeRestoredStateForKey获取前次状态
Bundle restoredState = registry.consumeRestoredStateForKey(key);
// 创建一个Handle
SavedStateHandle handle =
SavedStateHandle.createHandle(restoredState, defaultArgs);
// 生成SavedStateHandleController实例
SavedStateHandleController controller =
new SavedStateHandleController(key, handle);
// 这里进行了绑定
controller.attachToLifecycle(registry, lifecycle);
tryToAddRecreator(registry, lifecycle);
return controller;
}
void attachToLifecycle(SavedStateRegistry registry, Lifecycle lifecycle) {
registry.registerSavedStateProvider(mKey, mHandle.savedStateProvider());
}
至此，SavedStateProvider和SavedStateRegistry实现关联。
以上就是整个保存流程的概况，而还原流程差距不大，只是在onCreate()中调用SavedStateRegistryController.performRestore()，最终通知SavedStateRegistry在Bundle中恢复设置的数据。
/ 总结 /
忽略SavedStateHandleController对VM的确保机制 (包含Recreator)，最后总结：
初始化阶段
ComponentActivity创建了RegistryController实例；RegistryController创建了内部的Registry实例；ComponentActivity创建了Factory，并传入RegistryController维护的Registry。
恢复阶段
ComponentActivity在onCreate调用RegistryController的performRestore；RegistryController的performRestore中，调用Registry的performRestore；Registry的performRestore中，把数据从savedInstanceState (Bundle)取出，并储存到mRestoredState中。在此处Registry已把数据恢复。
VM生成阶段
VM需要通过Factory创建，创建VM对应的HandleController实例，通过Registry的consumeRestoredStateForKey把数据取出生成Handle。Handle内部维护一个Provider实例，共享数据容器mRegular；HandleController被注入Handle；Provider绑定到Registry，在此处实现了 (RegistryController-Registry-Provider-Handle) 绑定。VM被Factory注入Handle，在此处实现了 (RegistryController-Registry-Provider-Handle-VM) 绑定。VM数据最终通过Registry恢复。
写数据阶段
VM读写的数据最终存放到Handle的mRegular中。VM数据最终通过Registry保存。
保存阶段
ComponentActivity在onSaveInstanceState调用RegistryController的performSave，RegistryController的performSave中，调用Registry的performSave。Registry的performSave中，将所有注册的Provider数据打包成一个Bundle保存到onSaveInstanceState的Bundle中。
推荐阅读：
面试必问，事件分发机制你肯定得懂
细说Android中复杂的屏幕刷新机制
Kotlin vs Flutter，我到底应该怎么选？
欢迎关注我的公众号
学习技术或投稿
长按上图，识别图中二维码即可关注