android 架构设计,Android框架设计之MVVM

一、简介

1、定义

MVVM 模式(Model--View--ViewModel 模式)

Model：模型层，负责处理数据的加载或存储。与MVP中的M一样。

View：视图层，对应于Activity，XML,View，负责界面数据的展示，与用户进行交互。与MVP中的V一样。

ViewModel：视图模型，负责完成View于Model间的绑定和交互,Model或者View更改时，实时刷新对方，负责业务逻辑。

2、详情

和 MVP 模式相比，MVVM 模式用ViewModel 替换了 Presenter ，其他层基本上与 MVP 模式一致，ViewModel 可以理解成是 View 的数据模型和 Presenter 的合体。

MVVM 采用双向绑定(data-binding)：View 的变动，自动反映在 ViewModel，反之亦然，

这种模式实际上是框架替应用开发者做了一些工作(相当于 ViewModel 类是由库帮我们生

成的)，开发者只需要较少的代码就能实现比较复杂的交互。

3、各模块关系

MVVM 的调用关系和 MVP 一样。但是，在 ViewModel 当中会有一个叫 Binder，或者是Data-binding engine 的东西。以前全部由 Presenter 负责的 View 和 Model 之间数据同步操作交由给 Binder 处理。你只需要在 View 的模版语法当中，指令式地声明 View 上的显示的内容是和 Model 的哪一块数据绑定的。当 ViewModel 对进行 Model 更新的时候，Binder会自动把数据更新到 View 上去，当用户对 View 进行操作(例如表单输入)，Binder 也会自动把数据更新到 Model 上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会根据数据变更实时渲染。

二、MVVM案例

此案例基于MVP的案例,改为MVVM模式。其中ViewModel会跟View进行绑定，这里会用到Android的 Data Binding，关于DataBinding可以参考此文

首先在需要用到DataBinding模块的build.gradle中添加以下两句配置(kotlin需要加第一句，Java不需要)

image.png

Model层

data class UserModel(var userName:String){

fun login(result: Int, listener: ModelCallBack){

if (result == 1){

listener.onSuccess("${userName}登录成功")

}else{

listener.onFailed("${userName}登录失败")

}

}

//回调接口

interface ModelCallBack{

fun onSuccess(msg:String)

fun onFailed(msg:String)

}

}

View层

将根布局修改为layout，加入 Data Binding。

注意：class名为xml名去掉_后的驼峰写法，即此xml为activity_main.xml，则其类名则需要为ActivityMainBinding。两者名字必须是这个规则的写法，否则在View层进行xml绑定时会显示找不到xml文件

xmlns:app="http://schemas.android.com/apk/res-auto">

name="userViewModel"

type="yzl.swu.mvvm.viewModel.UserViewModel" />

android:layout_width="match_parent"

android:layout_height="match_parent">

android:id="@+id/textView"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@={userViewModel.userName}"

android:textSize="50sp"

app:layout_constraintBottom_toBottomOf="parent"

app:layout_constraintLeft_toLeftOf="parent"

app:layout_constraintRight_toRightOf="parent"

app:layout_constraintTop_toTopOf="parent"

app:layout_constraintVertical_bias="0.35" />

android:id="@+id/loginBtn"

android:layout_width="100dp"

android:layout_height="50dp"

android:layout_marginTop="30dp"

android:text="登录"

app:layout_constraintEnd_toEndOf="parent"

app:layout_constraintHorizontal_bias="0.5"

app:layout_constraintStart_toStartOf="parent"

app:layout_constraintTop_toBottomOf="@+id/textView"

android:onClick="@{userViewModel.loginUser}"/>

build一下生成需要的类

再到MainActivity中进行View和ViewModel的绑定

class MainActivity : AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

//DataBindingUtil.setContentView()方法返回一个数据绑定对象，其命名规则由系统自动生成

DataBindingUtil.setContentView(this,R.layout.activity_main).apply {

//将View和Model进行绑定

val userModel = UserViewModel()

userViewModel = userModel

}

}

}

ViewModel层

ViewModel负责业务逻辑处理，并且数据有更新直接通知View去更改。

class UserViewModel: BaseObservable() {

lateinit var userModel:UserModel

var userName:String? = null

//该注解用于双向绑定，需要与 notifyPropertyChanged()方法结合使用

//该注解用于标记实体类中的get方法或“is”开头的方法,且实体类必须继承BaseObservable

//使用@Bindable注解标记的get方法，在编译时，会在BR类中生成对应的字段，然后与notifyPropertyChanged()方法配合使用，当该字段中的数据被修改时，dataBinding会自动刷新对应view的数据

@Bindable

get() {

if (field != null) return field

return null

}

set(value) {

field = value

//更新UI

notifyPropertyChanged(BR.userName)

}

fun loginUser(view:View){

userModel = UserModel("用户${(0..9).random()}")

//点击事件的处理 直接交给Model层

userModel.login((0..1).random(),object:UserModel.ModelCallBack{

override fun onSuccess(msg: String) {

userName = msg

}

override fun onFailed(msg: String) {

userName = msg

}

})

}

}

运行结果

mvvm-gif.gif

三、总结

MVP和MVVM的区别

ViewModel与View绑定后，ViewModel与View其中一方的数据更新都能立即通知到对方，Presenter需要通过接口去通知View进行更新。

关键点

MVVM 把 View 和 Model 的同步逻辑自动化了。以前 Presenter 负责的 View 和 Model 同步不再手动地进行操作，而是交由框架所提供的 Binder 进行负责。

只需要告诉 Binder，View 显示的数据对应的是 Model 哪一部分即可。

MVVM的优缺点

优点

提高可维护性。解决了 MVP 大量的手动 View 和 Model同步的问题，提供双向绑定机制。提高了代码的可维护性。

简化测试。因为同步逻辑是交由 Binder 做的，View 跟着 Model 同时变更，所以只需要保证 Model 的正确性，View就正确。大大减少了对 View 同步更新的测试。

缺点

过于简单的图形界面不适用，或说牛刀杀鸡。

对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。

数据绑定的声明是指令式地写在 View 的模版当中的，这些内容是没办法去打断点 debug 的。

结语

可以看到，从 MVC->MVP->MVVM，就像一个打怪升级的过程。后者解决了前者遗留的问题，把前者的缺点优化成了优点。同样的 Demo 功能，代码从最开始的一堆文件，优化成了最后只需要 20 几行代码就完成。

但也不是说MVVM一定比其他两种模式要好，在实际中因根据各模式的优缺点及需求选择。