[移动开发]Android JetPack 之 ViewModel 使用及源码分析

ViewModel?类旨在以注重生命周期的方式存储和管理界面相关的数据。?ViewModel?类让数据可在发生屏幕旋转等配置更改后继续留存。

这是摘抄自官网的一段话：? 传送门

在使用Android提供的四大组件开发应用时，自身的业务还要结合组件的生命周期，各组件都有自己的生命周期，如Activity的生命周期：

onCreate ==> onStart ==> onResume ==> runing....? ==> onPause?==> onStop ==> onDestory

设想一种场景 业务首页 要展示一个用户列表项，这个用户列表项中的数据是从服务器拉取下来的，这个拉取数据的动作，放在了 onCreate中，这是很常见的一种写法：

List<UserItem> mList;

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.home_activity_splash);
        //开启子线程，从服务器端拉取数据
        mHelper.pullData();
    }



public void onDataPrepare(List<UserItem> data){
    mList = data;
    //展示UI
    showUsers(mList);
}

这样写在一般情况下没啥毛病，但是如果考虑以下两种情况，就会发现有问题：

1、用户进入业务首页，触发onCreate方法，然后正常下拉数据，数据拉取到之后更新UI展示给用户。但在这使用过程中，用户旋转手机，手机由竖屏变为横屏，也就触发了Android系统中所谓的配置变化，当配置变化发生时，用户正在使用的Activity就会经历：销毁、重建。

销毁、就会导致已经拉取到的数据被回收，重建之后又会调用onCreate方法，再次请求服务器拉取数据。

2、除了第一种情况外，还要考虑一下这种场景：用户进入业务首页 触发onCreate方法，下拉数据，但是下拉数据的过程由于网络原因可能非常慢，在这期间用户切换到其他APP去了，那么当前这个正在拉取数据的Activity就由可见状态变为了不可见状态，体现到Activity生命周期：

onResume ==> onPause ==> onStop

好巧不巧，用户正在其他APP上愉快的玩耍时，你的Activity已经成功从服务器端拉取到了数据，并将数据传送到Activity上，然后触发展示UI的操作。你的业务在展示UI时会有炫酷的动画效果，但这并没啥用，因为用户正在其他APP上玩耍，根本看不到这动画效果。其实正常的流程应该是当前Activity为可见状态时才触发展示UI操作。

基于上述两种情况，不难发现，我们自身的业务其实是要和Activity的生命周期紧密结合的，在适当的时候保留数据、展示UI。

其实要解决上述两个问题不是啥难事，像是数据由于屏幕旋转被销毁、重建，完全可以把第一次拉取到的数据放到一个静态成员上、又或者是通过系统调用的onSaveInstanceState()方法保留数据，随后在? onCreate? -> Bundle savedInstanceState 中获取到数据，对于第二种情况也可以根据当前Activity的生命周期来判断是否展示UI等。

使用ViewModel就可以优雅的解决上述问题了

ViewModel常规使用：

private MyViewModel mViewModel;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.home_activity_splash);
        mViewModel = new ViewModelProvider(this).get(MyViewModel.class);
        //添加观察者，当数据拉取成功时展示UI
        mViewModel.getUsersLiveData().observe(this, new Observer<String>() {
            @Override
            public void onChanged(List<UserItem> list) {
                showUsers(list);
            }
        //拉取数据
        mViewModel.pullData();
 }

这里面涉及到的LiveData在本篇中不予讨论，有MVVM开发模式经验的伙伴肯定都知道这是个啥，这里只重点讨论ViewModel。

看一张ViewModel的生命周期图，再结合上面的ViewModel简单应用：

?这张图来自官网： 传送门

?疑惑：

?这段获取mViewModel的代码也是写在onCreate方法中的：

mViewModel = new ViewModelProvider(this).get(MyViewModel.class);

那么在发生屏幕旋转导致的Activity销毁、重建后调用了onCreate，那岂不是又重写创建了ViewModel? ViewModel到底是如何实现经历销毁、重建后仍然保留之前的数据呢？带着这样的疑问来分析分析ViewModel的源码就会明白了。

看切入的第一个类 ViewModelProvider 的构造方法：

public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {
        this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory
                ? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory()
                : NewInstanceFactory.getInstance());
    }


    public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
        this(owner.getViewModelStore(), factory);
    }

    public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
        mFactory = factory;
        mViewModelStore = store;
    }

最终是调用到第三个构造函数，他做了一件很简单的事情，那就是为类实例成员编译赋值

ViewModelStore ->>> 存储ViewModel的一个容器，后面会分析
Factory ->>> 创建ViewModel的工厂类

继续看这一句：

mViewModel = new ViewModelProvider(this).get(MyViewModel.class);

创建了ViewModelProvider 之后，又调用了ViewModelProvider 的 get 方法，传入一个Class类型的参数，根据传入的类型，由Factory帮我们创建这个类的实例。

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");
        }
        //根据类名，拼接成key
        return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
    }


public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
        //从ViewModelStore中根据 key 去取实例
        ViewModel viewModel = mViewModelStore.get(key);

        /**如果ViewModelStore中没取到，那就由Factory去创建，并将实例存入ViewModelStore中**/
        
        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;
    }

上面的逻辑大致可以总结为：

1、尝试从ViewModelStore中获取所需的实例

2、如果第一步中成功获取到所需的实例对象，那么就可以返回了

3、如果第一步中返回的是null，那么就由Factory来创建这个所需的实例，创建之后的实例存入到ViewModelStore中，这个ViewModelStore相当于一个缓存容器。

ViewModelStore是个啥呢？ 其实看它提供的操作，很容易看出这就是一个容器罢了，瞄一眼它的代码：

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();
    }
}

果然，就是个容器。。。

回头看，探索源码的目的是为了了解，ViewModel是如何实现Activity经过销毁、重建后仍然可以保留数据的，但是分析至此，也没发现有什么特别的地方，还是不能解释 ViewModel的生命周期。