概述
ViewModel 相关问题是高频面试题。主要源于它是 MVVM 架构模式的重要组件,并且它可以在因配置更改导致页面销毁重建时依然保留 ViewModel 实例。
看看 ViewModel 的生命周期
ViewModel 只有在正常 Activity finish 时才会被清除。
问题来了:
- 为什么Activity旋转屏幕后ViewModel可以恢复数据
- ViewModel 的实例缓存到哪儿了
- 什么时候 ViewModel#onCleared() 会被调用
在解决这三个问题之前,回顾下 ViewModel 的用法特性
基本使用
MainRepository
class MainRepository { suspend fun getNameList(): List<String> { return withContext(Dispatchers.IO) { listOf("张三", "李四") } } }
MainViewModel
class MainViewModel: ViewModel() { private val nameList = MutableLiveData<List<String>>() val nameListResult: LiveData<List<String>> = nameList private val mainRepository = MainRepository() fun getNames() { viewModelScope.launch { nameList.value = mainRepository.getNameList() } } }
MainActivity
class MainActivity : AppCompatActivity() { // 创建 ViewModel 方式 1 // 通过 kotlin 委托特性创建 ViewModel // 需添加依赖 implementation 'androidx.activity:activity-ktx:1.2.3' // viewModels() 内部也是通过 创建 ViewModel 方式 2 来创建的 ViewModel private val mainViewModel: MainViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate (savedInstanceState) setContentView(R.layout.activity_main) // 创建 ViewModel 方式 2 val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java) mainViewModel.nameListResult.observe(this, { Log.i("MainActivity", "mainViewModel: nameListResult: $it") Log.i("MainActivity", "MainActivity: ${this@MainActivity} mainViewModel: $mainViewModel mainViewModel.nameListResult: ${mainViewModel.nameListResult}") }) mainViewModel.getNames() } }
测试步骤:打开app -> 正常看到日志
18:03:02.575 : mainViewModel: nameListResult: [张三, 李四] 18:03:02.575 : com.yqy.myapplication.MainActivity@7ffa77 mainViewModel: com.yqy.myapplication.MainViewModel@29c0057 mainViewModel.nameListResult: androidx.lifecycle.MutableLiveData@ed0d744
接着测试步骤:打开设置更换系统语言 -> 切换到当前app所在的任务 再看日志
18:03:59.622 : mainViewModel: nameListResult: [张三, 李四] 18:03:59.622 : com.yqy.myapplication.MainActivity@49a4455 mainViewModel: com.yqy.myapplication.MainViewModel@29c0057 mainViewModel.nameListResult: androidx.lifecycle.MutableLiveData@ed0d744
神奇!MainActivity 被重建了,而 ViewModel 的实例没有变,并且 ViewModel 对象里的 LiveData 对象实例也没变。 这就是 ViewModel 的特性。
ViewModel 出现之前,Activity 可以使用 onSaveInstanceState() 方法保存,然后从 onCreate() 中的 Bundle 恢复数据,但此方法仅适合可以序列化再反序列化的少量数据(IPC 对 Bundle 有 1M 的限制),而不适合数量可能较大的数据,如用户信息列表或位图。 ViewModel 的出现完美解决这个问题。
我们先看看 ViewModel 怎么创建的: 通过上面的实例代码,最终 ViewModel 的创建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
神奇!MainActivity 被重建了,而 ViewModel 的实例没有变,并且 ViewModel 对象里的 LiveData 对象实例也没变。 这就是 ViewModel 的特性。
ViewModel 出现之前,Activity 可以使用 onSaveInstanceState() 方法保存,然后从 onCreate() 中的 Bundle 恢复数据,但此方法仅适合可以序列化再反序列化的少量数据(IPC 对 Bundle 有 1M 的限制),而不适合数量可能较大的数据,如用户信息列表或位图。 ViewModel 的出现完美解决这个问题。
我们先看看 ViewModel 怎么创建的: 通过上面的实例代码,最终 ViewModel 的创建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
创建 ViewModelProvider 对象并传入了 this 参数,然后通过 ViewModelProvider#get 方法,传入 MainViewModel 的 class 类型,然后拿到了 mainViewModel 实例。
ViewModelProvider 的构造方法
public ViewModelProvider(@NonNull ViewModelStoreOwner owner) { // 获取 owner 对象的 ViewModelStore 对象 this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory ? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory() : NewInstanceFactory.getInstance()); }
ViewModelProvider 构造方法的参数类型是 ViewModelStoreOwner ?ViewModelStoreOwner 是什么?我们明明传入的 MainActivity 对象呀! 看看 MainActivity 的父类们发现
public class ComponentActivity extends androidx.core.app.ComponentActivity implements ... // 实现了 ViewModelStoreOwner 接口 ViewModelStoreOwner, ...{ private ViewModelStore mViewModelStore; // 重写了 ViewModelStoreOwner 接口的唯一的方法 getViewModelStore() @NonNull @Override 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."); } ensureViewModelStore(); return mViewModelStore; }
ComponentActivity 类实现了 ViewModelStoreOwner 接口。 奥 ~~ 刚刚的问题解决了。
再看看刚刚的 ViewModelProvider 构造方法里调用了 this(ViewModelStore, Factory),将 ComponentActivity#getViewModelStore 返回的 ViewModelStore 实例传了进去,并缓存到 ViewModelProvider 中
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) { mFactory = factory; // 缓存 ViewModelStore 对象 mViewModelStore = store; }
接着看 ViewModelProvider#get 方法做了什么
@MainThread 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); }
获取 ViewModel 的 CanonicalName , 调用了另一个 get 方法
@MainThread public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) { // 从 mViewModelStore 缓存中尝试获取 ViewModel viewModel = mViewModelStore.get(key); // 命中缓存 if (modelClass.isInstance(viewModel)) { if (mFactory instanceof OnRequeryFactory) { ((OnRequeryFactory) mFactory).onRequery(viewModel); } // 返回缓存的 ViewModel 对象 return (T) viewModel; } else { //noinspection StatementWithEmptyBody if (viewModel != null) { // TODO: log a warning. } } // 使用工厂模式创建 ViewModel 实例 if (mFactory instanceof KeyedFactory) { viewModel = ((KeyedFactory) mFactory).create(key, modelClass); } else { viewModel = mFactory.create(modelClass); } // 将创建的 ViewModel 实例放进 mViewModelStore 缓存中 mViewModelStore.put(key, viewModel); // 返回新创建的 ViewModel 实例 return (T) viewModel; }
mViewModelStore 是啥?通过 ViewModelProvider 的构造方法知道 mViewModelStore 其实是我们 Activity 里的 mViewModelStore 对象,它在 ComponentActivity 中被声明。 看到了 put 方法,不难猜它内部用了 Map 结构。
public class ViewModelStore { // 果不其然,内部有一个 HashMap private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) { ViewModel oldViewModel = mMap.put(key, viewModel); if (oldViewModel != null) { oldViewModel.onCleared(); } } // 通过 key 获取 ViewModel 对象 final ViewModel get(String key) { return mMap.get(key); } Set<String> keys() { return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() { for (ViewModel vm : mMap.values()) { vm.clear(); } mMap.clear(); } }
到这儿正常情况下 ViewModel 的创建流程看完了,似乎没有解决任何问题~ 简单总结:ViewModel 对象存在了 ComponentActivity 的 mViewModelStore 对象中。 第二个问题解决了:ViewModel 的实例缓存到哪儿了
转换思路 mViewModelStore 出现频率这么高,何不看看它是什么时候被创建的呢?
记不记得刚才看 ViewModelProvider 的构造方法时 ,获取 ViewModelStore 对象时,实际调用了 MainActivity#getViewModelStore() ,而 getViewModelStore() 实现在 MainActivity 的父类 ComponentActivity 中。
// ComponentActivity#getViewModelStore() @Override 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."); } ensureViewModelStore(); return mViewModelStore; }
在返回 mViewModelStore 对象之前调用了 ensureViewModelStore()
void ensureViewModelStore() { if (mViewModelStore == null) { NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance(); if (nc != null) { // Restore the ViewModelStore from NonConfigurationInstances mViewModelStore = nc.viewModelStore; } if (mViewModelStore == null) { mViewModelStore = new ViewModelStore(); } } }
当 mViewModelStore == null 调用了 getLastNonConfigurationInstance() 获取 NonConfigurationInstances 对象 nc,当 nc != null 时将 mViewModelStore 赋值为 nc.viewModelStore,最终 viewModelStore == null 时,才会创建 ViewModelStore 实例。
不难发现,之前创建的 viewModelStore 对象被缓存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的静态内部类 static final class NonConfigurationInstances { Object custom; // 果然在这儿 ViewModelStore viewModelStore; }
当 mViewModelStore == null 调用了 getLastNonConfigurationInstance() 获取 NonConfigurationInstances 对象 nc,当 nc != null 时将 mViewModelStore 赋值为 nc.viewModelStore,最终 viewModelStore == null 时,才会创建 ViewModelStore 实例。
不难发现,之前创建的 viewModelStore 对象被缓存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的静态内部类 static final class NonConfigurationInstances { Object custom; // 果然在这儿 ViewModelStore viewModelStore; }
NonConfigurationInstances 对象通过 getLastNonConfigurationInstance() 来获取的
// Activity#getLastNonConfigurationInstance /** * Retrieve the non-configuration instance data that was previously * returned by {@link #onRetainNonConfigurationInstance()}. This will * be available from the initial {@link #onCreate} and * {@link #onStart} calls to the new instance, allowing you to extract * any useful dynamic state from the previous instance. * * <p>Note that the data you retrieve here should <em>only</em> be used * as an optimization for handling configuration changes. You should always * be able to handle getting a null pointer back, and an activity must * still be able to restore itself to its previous state (through the * normal {@link #onSaveInstanceState(Bundle)} mechanism) even if this * function returns null. * * <p><strong>Note:</strong> For most cases you should use the {@link Fragment} API * {@link Fragment#setRetainInstance(boolean)} instead; this is also * available on older platforms through the Android support libraries. * * @return the object previously returned by {@link #onRetainNonConfigurationInstance()} */ @Nullable public Object getLastNonConfigurationInstance() { return mLastNonConfigurationInstances != null ? mLastNonConfigurationInstances.activity : null; }
好长一段注释,大概意思有几点:
- onRetainNonConfigurationInstance 方法和 getLastNonConfigurationInstance 是成对出现的,跟 onSaveInstanceState 机制类似,只不过它是仅用作处理配置更改的优化。
- 返回的是 onRetainNonConfigurationInstance 返回的对象
onRetainNonConfigurationInstance 和 getLastNonConfigurationInstance 的调用时机在本篇文章不做赘述,后续文章会进行解释。
看看 onRetainNonConfigurationInstance 方法
/** * 保留所有适当的非配置状态 */ @Override @Nullable @SuppressWarnings("deprecation") public final Object onRetainNonConfigurationInstance() { // Maintain backward compatibility. Object custom = onRetainCustomNonConfigurationInstance(); ViewModelStore viewModelStore = mViewModelStore; // 若 viewModelStore 为空,则尝试从 getLastNonConfigurationInstance() 中获取 if (viewModelStore == null) { // No one called getViewModelStore(), so see if there was an existing // ViewModelStore from our last NonConfigurationInstance NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance(); if (nc != null) { viewModelStore = nc.viewModelStore; } } // 依然为空,说明没有需要缓存的,则返回 null if (viewModelStore == null && custom == null) { return null; } // 创建 NonConfigurationInstances 对象,并赋值 viewModelStore NonConfigurationInstances nci = new NonConfigurationInstances(); nci.custom = custom; nci.viewModelStore = viewModelStore; return nci; }
到这儿我们大概明白了,Activity 在因配置更改而销毁重建过程中会先调用 onRetainNonConfigurationInstance 保存 viewModelStore 实例。 在重建后可以通过 getLastNonConfigurationInstance 方法获取之前的 viewModelStore 实例。
现在解决了第一个问题:为什么Activity旋转屏幕后ViewModel可以恢复数据
再看第三个问题:什么时候 ViewModel#onCleared() 会被调用
public abstract class ViewModel { protected void onCleared() { } @MainThread final void clear() { mCleared = true; // Since clear() is final, this method is still called on mock objects // and in those cases, mBagOfTags is null. It'll always be empty though // because setTagIfAbsent and getTag are not final so we can skip // clearing it if (mBagOfTags != null) { synchronized (mBagOfTags) { for (Object value : mBagOfTags.values()) { // see comment for the similar call in setTagIfAbsent closeWithRuntimeException(value); } } } onCleared(); } }
onCleared() 方法被 clear() 调用了。 刚才看 ViewModelStore 源码时好像是调用了 clear() ,回顾一下:
public class ViewModelStore { private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) { ViewModel oldViewModel = mMap.put(key, viewModel); if (oldViewModel != null) { oldViewModel.onCleared(); } } final ViewModel get(String key) { return mMap.get(key); } Set<String> keys() { return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() { for (ViewModel vm : mMap.values()) { vm.clear(); } mMap.clear(); } }
onCleared() 方法被 clear() 调用了。 刚才看 ViewModelStore 源码时好像是调用了 clear() ,回顾一下:
public class ViewModelStore { private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) { ViewModel oldViewModel = mMap.put(key, viewModel); if (oldViewModel != null) { oldViewModel.onCleared(); } } final ViewModel get(String key) { return mMap.get(key); } Set<String> keys() { return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() { for (ViewModel vm : mMap.values()) { vm.clear(); } mMap.clear(); } }
在 ViewModelStore 的 clear() 中,遍历 mMap 并调用 ViewModel 对象的 clear() , 再看 ViewModelStore 的 clear() 什么时候被调用的:
// ComponentActivity 的构造方法 public ComponentActivity() { ... getLifecycle().addObserver(new LifecycleEventObserver() { @Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) { if (event == Lifecycle.Event.ON_DESTROY) { // Clear out the available context mContextAwareHelper.clearAvailableContext(); // And clear the ViewModelStore if (!isChangingConfigurations()) { getViewModelStore().clear(); } } } }); ... }
观察当前 activity 生命周期,当 Lifecycle.Event == Lifecycle.Event.ON_DESTROY,并且 isChangingConfigurations() 返回 false 时才会调用 ViewModelStore#clear 。
// Activity#isChangingConfigurations() /** * Check to see whether this activity is in the process of being destroyed in order to be * recreated with a new configuration. This is often used in * {@link #onStop} to determine whether the state needs to be cleaned up or will be passed * on to the next instance of the activity via {@link #onRetainNonConfigurationInstance()}. * * @return If the activity is being torn down in order to be recreated with a new configuration, * returns true; else returns false. */ public boolean isChangingConfigurations() { return mChangingConfigurations; }
isChangingConfigurations 用来检测当前的 Activity 是否因为 Configuration 的改变被销毁了, 配置改变返回 true,非配置改变返回 false。
总结,在 activity 销毁时,判断如果是非配置改变导致的销毁, getViewModelStore().clear() 才会被调用。
第三个问题:什么时候 ViewModel#onCleared() 会被调用 解决!
以上就是Android ViewModel的使用总结的详细内容,更多关于Android ViewModel的使用的资料请关注靠谱客其它相关文章!
最后
以上就是大意蜜粉为你收集整理的Android ViewModel的使用总结的全部内容,希望文章能够帮你解决Android ViewModel的使用总结所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复