Android mvvm框架之ViewModel

Posted 2023-03-31 m0_67617498

// 我们看到了 ViewModel 在 ViewModelStore 中的 key 表示

return get(DEFAULT_KEY + “:” + canonicalName, modelClass);

public T get(@NonNull String key, @NonNull Class modelClass)

// 先检查缓存中是否存在

ViewModel viewModel = mViewModelStore.get(key);

if (modelClass.isInstance(viewModel))

//noinspection unchecked

return (T) viewModel;

else

//noinspection StatementWithEmptyBody

if (viewModel != null)

// TODO: log a warning.

// 缓存中没有，通过 Factory 构造

if (mFactory instanceof KeyedFactory)

viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);

else

viewModel = (mFactory).create(modelClass);

// 新实例保存缓存

mViewModelStore.put(key, viewModel);

//noinspection unchecked

return (T) viewModel;

3 ViewModel 与配置无关的原理（与宿主 Controller 俱生俱灭）

上一节我们说到，ViewModel 之所以能够与宿主 Controller 保持生命周期一致，是因为存储它的 ViewModelStore 与宿主 Controller 生命周期一致。那么为什么 ViewModelStore 能够保持和 Controller 生命周期一致呢？

这里我们需要先理清 FragmentActivity 和其寄生的 Fragment 的 ViewModelStore 之间的关系：

3.1 ViewModelStore 树

如图所示：

• 每个 ViewModelStore 依附于其宿主 Controller，所以各个 Controller 的 ViewModelStore 组成一个树状的引用关系；

• 处于顶层的 ViewModelStore 依附于 FragmentActivity，它除了保存用户级的 ViewModel 以外，还保存其儿子 Fragment 的 FragmentManagerViewModel；

• FragmentManagerViewModel 主要维护两个对象：所属 Fragment 的 ViewModelStore 和其儿子 Fragment 的 FragmentManagerViewModel 的引用，注意图中的红色部分，所有二级及以下的子孙 Fragment 都共用同一个父节点的 Child FragmentManagerModel，这样当父 Fragment 销毁的时候方便一次性清除其所有子 Fragment 共用的 FragmentManagerViewModel；

• 但是二级及以下的子孙 Fragment 的 ViewModelStore 都是独立的，一个 Fragment 自身的 ViewModel 变化应该不影响其兄弟节点的 ViewModel，所以可以推导出，它们共同的 FragmentManagerViewModel 应该是维护了一个保存各个子 Fragment 的 ViewModelStore 的容器，大家如果细看 FragmentManagerViewModel 的源代码，实际上就是这么做的。

所以，我们看到，处于顶层的 FragmentActivity 的 ViewModelStore 是一个超级 Store，它引用了所有的 ViewModels，包括自身的数据、所有子孙 Fragment 的 ViewModels，只要各子孙 Fragment 不清除自有 ViewModelStore，则所有的数据都维护在这棵 ViewModelStore 树中。

那么在配置发生变化的时候，ViewModelStore 树如何保持不变呢？

3.2 系统级的配置无关支持

将 ViewModelStore 作为配置无关数据进行保持，在 FragmentActivity 中是这么做的：

是的，流程就是这么简单，只需要将 ViewModelStore 封装在一个特殊对象中保存并在 FragmentActivity 的 onRetainNonConfigurationInstance() 方法中返回即可：

/**

• Called by the system, as part of destroying an

• activity due to a configuration change, when it is known that a new

• instance will immediately be created for the new configuration. You

• can return any object you like here, including the activity instance

• itself, which can later be retrieved by calling

• @link #getLastNonConfigurationInstance() in the new activity

• instance.

*/

@Override

@Nullable

public final Object onRetainNonConfigurationInstance()

Object custom = onRetainCustomNonConfigurationInstance();

ViewModelStore viewModelStore = mViewModelStore;

// …省略与原理无关代码

NonConfigurationInstances nci = new NonConfigurationInstances();

nci.custom = custom;

nci.viewModelStore = viewModelStore;

return nci;

这样，在顶层源头上就保证了所有 Controller 的 ViewModels 不会在发送配置变化的时候由于 Controller 重建而被销毁。

另外在 Fragment 层中，必须区分 Fragment 实例销毁时到底是因为调用了 onDestroy 还是配置发生了变化，如果是前者则必须清理自身持有的 ViewModelStore，如果是后者则不能清理：

如图所示，也说明了 Fragment 的 ViewModel 生命周期与该 Fragment 生命周期是一致的。

// FragmentManagerImpl.moveToState()

//…省略

boolean beingRemoved = f.mRemoving && !f.isInBackStack(); // 是否 destroy，如果只是配置变化，则为 false

if (beingRemoved || mNonConfig.shouldDestroy(f))

boolean shouldClear;

if (mHost instanceof ViewModelStoreOwner)

// 说明这是第一层 Fragment，只要顶层 ViewModelStore 没有清除该 FragmentManagerViewModel 就说明不用清理

shouldClear = mNonConfig.isCleared();

else if (mHost.getContext() instanceof Activity)

// 说明是 FragmentActivity 的子孙 Fragment，根据是否是配置变化来判断是否需要清理

Activity activity = (Activity) mHost.getContext();

shouldClear = !activity.isChangingConfigurations();

else

shouldClear = true;

if (beingRemoved || shouldClear)

// 只有确实 destroy 了才需要清理

mNonConfig.clearNonConfigState(f);

f.performDestroy();

dispatchOnFragmentDestroyed(f, false);

//…省略

4 FragmentActivity 中的 ViewModel 生命周期

最后，我们还需要说明一下，FragmentActivity 中的 ViewModel 的生命周期是如何保持与 FragmentActivity 一致的，除了上一节中 FragmentActivity.onRetainNonConfigurationInstance() 中的配置无关保证以外，还需要保证在 Activity 真正销毁的时候其所持有的 ViewModel 也应该被清理。

其代码实现非常简单，只需要观察该 Activity 的 Lifecycle 状态，并在销毁状态时进行清理即可，关于 Lifecycle 我们将用专门的章节进行说明，以下为清理代码：

getLifecycle().addObserver(new LifecycleEventObserver()

@Override

public void onStateChanged(@NonNull LifecycleOwner source,

@NonNull Lifecycle.Event event)

if (event == Lifecycle.Event.ON_DESTROY)

// 观察到 Activity 被销毁

if (!isChangingConfigurations())

// 若不是配置变化，则清理

getViewModelStore().clear();

);

5 多 Controller 共享 ViewModel

我们参考第3.1节的 ViewModelStore 树可知，如果多个 Controller 需要共享同一个 ViewModel 的话，我们只需要将该 ViewModel 保存在这些 Controller 共同的父 Controller 的 ViewModelStore 中即可，而这些子 Controller 可以通过如下方式获取这个共享的 ViewModel：

[Fragment/FragmentActivity] parentContrl = … // 共同的父 Controller

final CommonViewModel viewModel = ViewModelProviders.of(parentContrl).get(CommonViewModel.class);

这样我们就解决了在 1.1 节中提到的第二个场景共享数据的问题。

6 关于工厂模式的一点思考

Android基础——框架模式MVVM之DataBinding的实践

---

 

本篇文章包含以下内容:

• MVVM的介绍
• MVVM的实践
  
  • DataBinding之layout标签的使用
  • DataBinding之data与variable标签的使用
  • DataBinding之绑定点击事件的使用

MVVM是Model-View-ViewModel的简写，这个模式提供对View和View Model的双向数据绑定，使得View Model的状态改变可以自动传递给View

• Model：数据层，负责处理数据的加载或者存储
• View：视图层，负责界面数据的展示，与用户进行交互
• ViewModel：负责完成View于Model间的交互,负责业务逻辑

MVVM的模型关系图：

MVVM优点：

• 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
• 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xml代码。
• 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

---

在安卓采用DataBinding来支持MVVM框架模式，下面我们以DataBinding来实践

实践工具：Android Studio 2.1

准备工作：开启安卓中的DataBinding，需要在Module下的build.gradle中声明

---

• layout标签作用：作为DataBinding的标志，省去findViewById()方法

第一步：我们以学生管理信息为例子，我们在布局文件的外层嵌套一层layout标签，并附上命名空间，在EditText和TextView中添加对应的ID

第二步：在我们的主Activity中，需要通过DataBindingUtil来绑定我们的xml布局

DataBindingUtil.setContentView()方法返回一个数据绑定对象，其命名规则由系统自动生成，由于我们的布局名字是activity_login.xml，所以生成规则：将下划线去掉，提取xml命名（字母首大写）+Binding

第三步：如果我们需要操作xml的View，则不需要findViewById()，直接调用binding对象里面的View即可，其控件的命名规则：将下划线去掉，提取xml命名（字母首大写）

---

• data与variable标签的作用：将对象传进布局xml文件

第一步：由于layout标签还需要在binding对象中使用View，还没有完全体现MVVM的真正效果，下面在布局文件声明data与variable标签

在variable中，我们取个name，并将它的type指向一个Bean对象，即绑定了该对象，在使用时，通过@{ }的格式，将对象的属性绑定到控件中

第二步：在主Activity中，只要设置这个对象即可

---

• 绑定onTextChanged事件：我们通过EditText的修改来更新TextView
• 绑定onClick事件：点击TextView弹出Toast

第一步：我们在主Activity中创建一个Controller类，kite注意这个onTextChange方法的名字和参数必须和EditText原生的onTextChange一致，还有onClick方法也是

第二步：在布局文件中，声明这个类，并给EditText加上onTextChanged事件，给TextView加上onClick事件

注意controller.onTextChanged和controller.onClick必须对应Controller里面的名字，Controller里面的方法名可以随便取，但是参数必须和原生的方法参数一致，否则编译报错

第三步：在主Activity中设置这个Controller

• 绑定onClickListener事件：将xml的对象传递给Activity，这也是MVVM双向数据绑定的体现

第一步：我们继续在主Activity中Controller类，创建该方法

第二步：我们在TextView中使用该方法，并将student对象传递到Activity中

这里用到的我们Lambda表达式，理解起来比较困难，大家知道就好了

源码

github：https://github.com/AndroidHensen/Design-Mode