1. 编程号首页

Android ViewModel，再学不会你砍我

编程小号 • • 未分类

Android ViewModel，再学不会你砍我MVVM与MVP相比最大的区别就是用ViewModel（后文简称VM）代替了原来的P层，这里的VM就是ViewModel。一句话概括它的特点-对数据状态的持有和维护。换言之，它将原来P层关于数据的逻辑运算与处理统一放到了VM中，而剩余的V层的操作建议使用Databindin…

之前工作用了很久MVP架构了，虽然很好的解决了M层与V层的耦合关系，但巨多的接口，难以复用、难以单测的问题一直萦绕心头，久久不能平复~~~，于是我将目光转向了MVVM。

首先声明，本篇不是ViewModel的使用介绍，更偏向底层原理，如果你还不清楚它的使用，不建议直接阅读~~

MVVM与MVP相比最大的区别就是用ViewModel（后文简称VM）代替了原来的P层，这里的VM就是ViewModel。一句话概括它的特点—对数据状态的持有和维护。换言之，它将原来P层关于数据的逻辑运算与处理统一放到了VM中，而剩余的V层的操作建议使用Databinding，从而形成最为简洁高效的MVVM架构。说到这呢，推荐一篇旧文DataBinding，再学不会你砍我（系兄弟就砍偶系列?）。

回到VM的特点—对数据状态的持有和维护。为什么需要做这些呢？事实上就是为了解决下面两个开发中常见的问题。

  • Activity配置更改重建时(比如屏幕旋转)保留数据
  • UI组件(Activity与Fragment、Fragment与Fragment)间实现数据共享。

对于第一条不用VM的情况下只能通过onSaveInstanceState保存数据，当activity重建后再通过onCreate或onRestoreInstanceState方法的bundle中取出，但如果数据量较大，数据的序列化和反序列化将产生一定的性能开销。

对于第二条如果不用VM，各个UI组件都要持有共享数据的引用，这会带来两个麻烦，第一，如果新增了共享数据，各个UI组件需要再次声明并初始化新增的共享数据；第二，某个UI组件对共享数据修改，无法直接通知其他UI组件，需手动实现观察者模式。而VM结合LiveData就可以很轻松的实现这一点。

LiveData作为数据变化的驱动器，VM借助它可以写出十分简洁的MVVM代码。

接下来我们来看一下VM到底是如何实现上述需求的，而事实上核心可以转化为下面两个问题。

问个正事.png

问题

  1. VM是如何解决Activity与Fragment、Fragment之间数据共享的问题？
  2. VM是如何在Activity发生旋转时保留数据的？不是也走onDestroy了吗？

ViewModel是什么？

回答上面问题之前我们要先了解一下VM到底是个啥。

文内源码来自，Android Architect Component（AAC）ViewModel组件1.1.1版本。

public abstract class ViewModel {
    protected void onCleared() {
    }
}

就是个抽象类甚至连抽象方法都没有，简单的令人发指。onCleared方法提供了释放VM中资源的一个机会，在Activity/Fragment的onDestroy生命周期中被调用。类库内部提供了一个实现类AndroidViewModel。

public class AndroidViewModel extends ViewModel {
    private Application mApplication;

    public AndroidViewModel(@NonNull Application application) {
        mApplication = application;
    }

    public <T extends Application> T getApplication() {
        return (T) mApplication;
    }
}

AndroidViewModel内持有Application的引用，所以通常可以做一些全生命周期的工作。为什么不能持有一个Activity呢？这与ViewModel的生命周期有关，我们稍后解释。

创建ViewModel

接下来看看VM的创建，通常我们是这样创建一个VM的。

val viewModel = ViewModelProviders.of(this).get(AndroidViewModel::class.java)

这里的this可以是FragmentActivity或Fragment，他们都是support-v4包中控件，为的是向下兼容。 我们以FragmentActivity为例看看of方法做了什么。

### 1.1 ViewModelProviders
public static ViewModelProvider of(@NonNull FragmentActivity activity) {
    return of(activity, null);
}

public static ViewModelProvider of(@NonNull FragmentActivity activity,
        @Nullable Factory factory) {
    Application application = checkApplication(activity);
    if (factory == null) {
        factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
    }
    //这里用的工厂模式，vm的创建交由工厂完成，默认使用AndroidViewModelFactory
    return new ViewModelProvider(ViewModelStores.of(activity), factory);
}

这两个方法的返回值都是ViewModelProvider，ViewModelProviders是操作ViewModelProvider的工具类，内部都是获取ViewModelProvider的静态方法，而真正的VM的业务在ViewModelProvider中。

同理ViewModelStores和ViewModelStore的关系亦是如此。既然要保留VM的数据，必然要有个存储单元。ViewModelStore就是这个存储单元，因为一个Activity中可能有多个VM，所以需要一个Map来维护关系表，key为VM的名字，value为VM对象，简单的令人发指。

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

    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.onCleared();
        }
        mMap.clear();
    }
}

ViewModelStores仅负责提供工具方法创建ViewModelStore。

### 1.2
public class ViewModelStores {
    private ViewModelStores() {
    }

    public static ViewModelStore of(@NonNull FragmentActivity activity) {
        if (activity instanceof ViewModelStoreOwner) {
            return ((ViewModelStoreOwner) activity).getViewModelStore();
        }
        return holderFragmentFor(activity).getViewModelStore();
    }
    ...
}

ViewModelStoreOwner又是什么鬼？它是抽象了一个获取ViewModelStore的接口。常见的实现类有Fragment/FragmentActivity，这也不难理解，因为要想在配置改变时保留数据，首先得要将数据存储起来。

public interface ViewModelStoreOwner {
    ViewModelStore getViewModelStore();
}

感觉这时需要一张类图了，不然你是不是想砍死我？

format.jpg

事实上目前提到的这几个类已经几乎涵盖了viewmodel库中所有的类。

我们回到1.1中创建ViewModelProvider的代码。

return new ViewModelProvider(ViewModelStores.of(activity), factory);

我们将activity中的VM存储单元和VM的创建工厂(AndroidViewModelFactory)传入得到一个ViewModelProvider对象，最终通过其get方法得到VM。

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

以Default_Key作为前缀加上VM的完整类名为key，获取VM对象。

public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
    ViewModel viewModel = mViewModelStore.get(key);

    //先看ViewModelStore中是否存在，如果存了就直接返回
    if (modelClass.isInstance(viewModel)) {
        return (T) viewModel;
    }
    ...
    //如果不存在，创建一个新的VM并存入ViewModelStore
    viewModel = mFactory.create(modelClass);
    mViewModelStore.put(key, viewModel);
    return (T) viewModel;
}

默认情况下mFactory为AndroidViewModelFactory，来看下它是如何创建VM的。

public static class AndroidViewModelFactory extends ViewModelProvider.NewInstanceFactory {
    ...
    public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
        if (AndroidViewModel.class.isAssignableFrom(modelClass)) {
            try {
                //通过反射创建AndroidViewModel对象
                return modelClass.getConstructor(Application.class).newInstance(mApplication);
            } catch (NoSuchMethodException e) {
                ...
            } 
        }
        return super.create(modelClass);
    }
}

至此VM的创建我们就讲完了，可以总结一下：

  1. ViewModelStore是存储VM的数据单元，存储结构为Map，Fragment/FragmentActivity持有其引用。
  2. ViewModelProvider通过get方法创建一个VM，创建之前会先检查ViewModelStore中是否存在，若不存在则通过反射创建一个VM。

UI组件间数据共享

讲到这我们回过头来看看开篇提的第一个问题：Activity与Fragment，Fragment之间是如何共享数据的。 数据要实现共享最简单的方式就是大家都读取一份数据源。 我们来看看数据源ViewModelStore具体是在哪里创建的。

上面讲的代码片段1.2可知，有两条路径创建。

public static ViewModelStore of(@NonNull FragmentActivity activity) {
    if (activity instanceof ViewModelStoreOwner) { ①
        return ((ViewModelStoreOwner) activity).getViewModelStore();
    }
    return holderFragmentFor(activity).getViewModelStore();②
}

①如果FragmentActivity是ViewModelStoreOwner类型通过activity的getViewModelStore方法创建。

②否则通过一个HolderFragment来创建。

先来看①

### FragmentActivity
private ViewModelStore mViewModelStore;
public ViewModelStore getViewModelStore() {
    ...
    if (mViewModelStore == null) {
        mViewModelStore = new ViewModelStore();
    }
    return mViewModelStore;
}

简单的令人发ck，既然是成员变量那每次调用必定返回同一个VM，只要保证调用ViewModelProviders.of(activity).get(AndroidViewModel::class.java)传递的activity是同一个对象。

再来看②，整体思路是添加一个不可见的HolderFragment到当前Activity中，再将数据源记录在这个fragment中。

### HolderFragment extends Fragment implements ViewModelStoreOwner
private ViewModelStore mViewModelStore = new ViewModelStore();

public static HolderFragment holderFragmentFor(FragmentActivity activity) {
    return sHolderFragmentManager.holderFragmentFor(activity);
}

HolderFragment holderFragmentFor(FragmentActivity activity) {
    FragmentManager fm = activity.getSupportFragmentManager();
    //先查一下当前有没有这个HolderFragment
    HolderFragment holder = findHolderFragment(fm);
    if (holder != null) {
        return holder;
    }
    ...
    //没有就创建一个
    holder = createHolderFragment(fm);
    ...
    return holder;
}

private static HolderFragment createHolderFragment(FragmentManager fragmentManager) {
    //创建一个HolderFragment、打上tag，再添加到当前界面。
    HolderFragment holder = new HolderFragment();
    fragmentManager.beginTransaction().add(holder, HOLDER_TAG).commitAllowingStateLoss();
    return holder;
}

之所以不可见，是因为这个HolderFragment并未复写onCreateView。这么做的原因是早期的版本想利用Fragment的setRetainInstance()API接口，来实现当Activity因配置发生改变时保留这个不可见的Fragment，生命周期只走onDetach和onAttach。既然没有被重建，那么它持有的数据自然就会被保留，其他主动退出的情况走到onDestroy会清空数据。

### HolderFragment
public HolderFragment() {
    setRetainInstance(true);
}
//被销毁时清除数据源
public void onDestroy() {
    super.onDestroy();
    mViewModelStore.clear();
}

那么在实际使用中会走哪条路径呢？我们反观源码FragmentActivity是实现了ViewModelStoreOwner接口的，那此处代码不是肯定走①吗？②是不是走错片场了？此时我感觉我的智商受到了侮辱。

智商不足.jpeg

原来在appcompat-v7版本在27.1.0之前FragmentActivity并没有实现ViewModelStoreOwner接口，也就是统一用HolderFragment实现。google大大可能是觉得这个HolderFragment有点太骚操作了就让后续版本的FragmentActivity直接支持了VM存储。因为添加的HolderFragment也是有维护成本的，且上层可以通过FragmentManager获取到它，然后对它进行其他骚操作，想想都刺激。。。

深井冰.jpg

上面我们分析了创建VM时传入FragmentActivity的情况，那传入Fragment的情况呢？实际上跟FragmentActivity几乎一样，在Fragment中也有一个mViewModelStore成员变量，注意这里哦，非常关键。也就是说如果我们通过下面的代码创建的是两个VM，是不能共享数据的。

### MainActivity
override fun onCreate(savedInstanceState: Bundle?) {
    //传递activity
    val vm = ViewModelProviders.of(this).get(AndroidViewModel::class.java)
}

### TestFragment
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    //传递fragment
    val vm = ViewModelProviders.of(this).get(AndroidViewModel::class.java)
}

正确的写法应该是二者在of方法中传入相同的对象

### TestFragment.onCreate(savedInstanceState: Bundle?)
//通过getActivity方法取得Fragment所在的Activity
val vm = activity?.run {
    //run函数 这里的this指代activity
    ViewModelProviders.of(this)[AndroidViewModel::class.java]
}

Fragment之间同理，如果Fragment间同层级，可以统一通过Activity或共同的parentFragment(如果有)获取VM；如果有嵌套关系，可以使用parentFragment对象获取VM。

Activity配置发生变化时数据保持

其实在上面的内容中已经讲了HolderFragment是如何保留数据的，就是利用Fragment的setRetainInstance()API接口完成的。

google为了优化这点在新版本里直接让FragmentActivity支持了数据的保持，官方的配图很好的阐释了VM在Activity因配置变化销毁重建时的生命周期。

viewmodel-lifecycle.png

下面我们来分析一下是如何做到的，先看onDestroy的销毁逻辑。

### FragmentActivity
protected void onDestroy() {
    super.onDestroy();
    ...
    if (mViewModelStore != null && !mRetaining) {
        mViewModelStore.clear();
    }
    ...
}

mRetaining为true时将会保留VM数据，那它何时为true呢？

### FragmentActivity
public final Object onRetainNonConfigurationInstance() {
    if (mStopped) {
        //方法内部会将mRetaining设置为true
        doReallyStop(true);
    }
    ...
    NonConfigurationInstances nci = new NonConfigurationInstances();
    nci.custom = custom;
    //保存VM数据
    nci.viewModelStore = mViewModelStore;
    nci.fragments = fragments;
    return nci;//数据返回会被记录
}

onRetainNonConfigurationInstance方法被retainNonConfigurationInstances方法调用，而它会被ActivityThread中performDestroyActivity方法调用，它执行在onDestroy生命周期之前。

### ActivityThread
performDestroyActivity(...boolean getNonConfigInstance,...) {
    ...
	if (getNonConfigInstance) {
	    //如果配置发生改变记录下来
        r.lastNonConfigurationInstances
                = r.activity.retainNonConfigurationInstances();
    }
}

这样VM数据就被封装到了NonConfigurationInstances一个对象中了。

那何时被还原呢？答案是Activity的attach时。

### Activity
final void attach(Context context, ... NonConfigurationInstances lastNonConfigurationInstances,...) {
    ...
	mLastNonConfigurationInstances = lastNonConfigurationInstances;
	...
}

VM数据源mViewModelStore在onCreate时被重新赋值。

### FragmentActivity
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    //还原数据
    NonConfigurationInstances nc =
            (NonConfigurationInstances) getLastNonConfigurationInstance();
    if (nc != null) {
        mViewModelStore = nc.viewModelStore;
    }
    ...
}

最后我们整理一下整体流程图。

代码流程.png

从上面的流程可以看出VM在Activity因配置变化导致重建时会被保留，从生命周期的角度来说，ViewModel的生命周期可能会长于Activity的生命周期。

这说明我们在使用ViewModel时一定要注意，不能让其引用Activity或View，否则可能导致内存泄漏。

好了，整个ViewModel的分析就结束了，希望你在了解其工作原理的同时对MVVM模式也有一些新的认识。独立的看ViewModel没有什么实际意义，更像是数据容器，结合LiveData使用更容易理解，后续章节会继续分享LiveData的内容。

今天的文章Android ViewModel，再学不会你砍我分享到此就结束了，感谢您的阅读。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/21027.html

赞 (0)
编程小号编程小号
0

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注