Android ViewModel的使用总结

目录
  • 基本使用
    • MainRepository
    • MainViewModel
    • MainActivity

ViewModel 相关问题是高频面试题。主要源于它是 MVVM 架构模式的重要组件,并且它可以在因配置更改导致页面销毁重建时依然保留 ViewModel 实例。

看看 ViewModel 的生命周期

ViewModel 只有在正常 Activity finish 时才会被清除。

问题来了:

  1. 为什么Activity旋转屏幕后ViewModel可以恢复数据
  2. ViewModel 的实例缓存到哪儿了
  3. 什么时候 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的使用的资料请关注我们其它相关文章!

(0)

相关推荐

  • Android通过ViewModel保存数据实现多页面的数据共享功能

    通过ViewModel实现的数据共享符合Android的MVC设计模式,将数据独立出来 实现的Demo 1.主页面通过SeekBar 来改变数字的值 2.点击进入就进入第二个界面,但是数据还是共享的 3.随便加两个数字上去,再次切换 4.发现数据还是共享的 下面是具体实现步骤: 1.建立两个Fragment(使用了Binding 和 Navigation) 一点要添加Binding 和 Navigation 不然做不了 2.建立一个继承于ViewModel的类 3.分别在两个Fragment的代

  • Android-ViewModel和LiveData使用详解

    ViewModel类的设计目的是以一种关注生命周期的方式存储和管理与UI相关的数据. 例如:Activity在配置发生改变时(屏幕旋转),Activity就会重新创建,onCreate()方法也会重新调用.我们可以在onSaveInstanceState()方法中保存数据,并从onCreate()方法中通过Bundle恢复数据,但这种方法只适用于可以对其进行序列化的少量数据,而不适用于潜在的大量数据.使用ViewModel的话ViewModel会自动保留之前的数据并给新的Activity或Fra

  • 解决android viewmodel 数据刷新异常的问题

    3年的wpf开发经验,自认为对数据驱动UI开发模式的使用不是问题,但当开始研究android的mvvm模式开发时,发现两年多的android开发经验已经将之前的wpf开发忘得7788了.感慨一下:人老了,记忆力就这么脆弱. 谈正题:adroid mvvm开发模式 之 viewmodel使用小麻烦. viewmodel public class MyViewModel extends ViewModel { private MutableLiveData<List<User>> mU

  • Android Jetpack架构组件 ViewModel详解

    前言 前面两篇文章我们已经学习了Lifecycle和DataBind,本篇文章我们来学习Jetpack系列中比较重要的ViewModel,Jetpack的很多很多组件都是搭配使用的,所以单独的知识点可能会有些"无意义"但却是我们项目实战的基础! ViewModel的使用 ViewModel类旨在以注重生命周期的方式存储和管理界面相关的数据.ViewModel类让数据可在发生屏幕旋转等配置更改后继续存在.这句话很好理解,还记得我们在讲解Lifecycle的时候 举的例子吗,我们还是使用那

  • Android ViewModel的使用总结

    目录 基本使用 MainRepository MainViewModel MainActivity ViewModel 相关问题是高频面试题.主要源于它是 MVVM 架构模式的重要组件,并且它可以在因配置更改导致页面销毁重建时依然保留 ViewModel 实例. 看看 ViewModel 的生命周期 ViewModel 只有在正常 Activity finish 时才会被清除. 问题来了: 为什么Activity旋转屏幕后ViewModel可以恢复数据 ViewModel 的实例缓存到哪儿了 什

  • Github简单易用的 Android ViewModel Retrofit框架

    目录 RequestViewModel Gradle 使用 1.retrofit接口的声明 2.retrofit配置 3.在Activity或Fragment中创建请求对象 4.继承RequestLiveData,处理返回数据 5.使用RequestViewModel和RequestLiveData请求数据 6.设置请求参数,主动请求数据 7.观察RequestLvieData数据变化 8.日志打印 RequestViewModel 优势: 快捷.方便地使用ViewModel .LiveData

  • Android Jetpack库剖析之ViewModel组件篇

    前言 今天让我们一起去探究一下ViewModel的实现原理,描述的不对或不足还请海涵,仅作为参考 ViewModel简介 ViewModel是一个可感知Activity或Fragment生命周期的一个架构组件,当视图销毁,数据也会被清除,所以它的本质就是用来存储与视图相关的数据,让视图显示控制与数据分离,即使界面配置发生改变数据也不会被销毁,通常配合LiveData使用 ViewModel用法 class MainActivity : AppCompatActivity() { override

  • Android Jetpack架构中ViewModel接口暴露的不合理探究

    目录 暴露 Mutable 状态 暴露 Suspend 方法 在 Jetpack 架构规范中, ViewModel 与 View 之间应该遵循单向数据流的通信方式,Events 永远从 View 流向 VM ,而 State 从 VM 流向 View. 如果 ViewModel 对 View 暴露了不适当的接口类型,则会破坏单向数据流的形成.不适当的接口类型常见于以下两点: 暴露 Mutable 状态 暴露 Suspend 方法 暴露 Mutable 状态 ViewModel 对外暴露的数据状态

  • 一文了解Android ViewModelScope 如何自动取消协程

    先看一下 ViewModel 中的 ViewModelScope 是何方神圣 val ViewModel.viewModelScope: CoroutineScope get() { val scope: CoroutineScope? = this.getTag(JOB_KEY) if (scope != null) { return scope } return setTagIfAbsent(JOB_KEY, CloseableCoroutineScope(SupervisorJob() +

  • Android开发Jetpack组件ViewModel使用讲解

    目录 前言 ViewModel概述 ViewModel使用 ViewModel源码 前言 学习ViewModel之前首先我们得简单了解下MVP和MVVM,因为ViewModel是MVVM中的一个元素 MVP MVVM 在MVP中View想要调用Model数据层,需要经过中间层Presenter, 这样就实现了View和Model的解耦,这也是MVP和MVC的差别: 但是如果一个Activity中有太多交互,那么我们的View接口数量就会很庞大达到十几个也不足为奇,并且在View层调用了Prese

  • Android Jetpack组件支持库DataBinding与ViewModel与LiveData及Room详解

    目录 一.官方推荐的Jetpack架构 二.添加依赖 三.创建Repository 四.创建ViewModel 五.activity中使用 Android Jetpack之ViewModel.LiveData Android Jetpack之LifeCycle 一.官方推荐的Jetpack架构 ViewModel是介于View(视图)和Model(数据模型)之间的中间层,能够使视图和数据分离,又能提供视图和数据之间的通信. LiveData是一个能够在ViewModel中数据发生变化时通知页面刷

随机推荐