Jetpack 之 MVVM

前置储备:LiveData
可以说 MVVM 的好处那是相当多了😁,至少我个人使用来说,是方便了不少❤。

logo

什么是 MVVM

说起 MVVM ,那就要大概提一提 MVC ,MVP 。当然,本文的重点并非 MVC & MVP。

先来说说 MVC

直接贴上维基百科的解释(https://zh.wikipedia.org/wiki/MVC)

即 模型(Model)-视图(View)-控制器(Controller)。
MVC模式(Model–view–controller)是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。

MVC模式最早由Trygve Reenskaug在1978年提出[1],是施乐帕罗奥多研究中心(Xerox PARC)在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程序设计,使后续对程序的修改和扩展简化,并且使程序某一部分的重复利用成为可能。除此之外,此模式通过对复杂度的简化,使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。

专业人员可以通过自身的专长分组:

  • 控制器(Controller)- 负责转发请求,对请求进行处理。

  • 视图(View) - 界面设计人员进行图形界面设计。

  • 模型(Model) - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

MVP

维基解释(https://zh.wikipedia.org/wiki/Model-view-presenter)

Model-view-presenter,简称MVP,是计算机软件设计工程中一种对针对MVC模式,再审议后所延伸提出的一种软件设计模式。

Model-View-Presenter (MVP) 是用户界面设计模式的一种,被广泛用于便捷自动化单元测试和在呈现逻辑中改良分离关注点(separation of concerns)。

  • Model 定义用户界面所需要被显示的数据模型,一个模型包含着相关的业务逻辑。
  • View 视图为呈现用户界面的终端,用以表现来自 Model 的数据,和用户命令路由再经过 Presenter 对事件处理后的数据。
  • Presenter 包含着组件的事件处理,负责检索 Model 获取数据,和将获取的数据经过格式转换与 View 进行沟通。

MVP 设计模式通常会再加上 Controller 做为整体应用程序的后端程序工作。

MVVM

维基(https://zh.wikipedia.org/wiki/MVVM)

  • MVVM 概述

MVVM(Model–view–viewmodel)是一种软件架构模式。

MVVM有助于将图形用户界面的开发与业务逻辑或后端逻辑(数据模型)的开发分离开来,这是通过置标语言或GUI代码实现的。MVVM的视图模型是一个值转换器,这意味着视图模型负责从模型中暴露(转换)数据对象,以便轻松管理和呈现对象。在这方面,视图模型比视图做得更多,并且处理大部分视图的显示逻辑。视图模型可以实现中介者模式,组织对视图所支持的用例集的后端逻辑的访问。

MVVM是马丁·福勒的PM(Presentation Model)设计模式的变体。MVVM以相同的方式抽象出视图的状态和行为,但PM以不依赖于特定用户界面平台的方式抽象出视图(创建了视图模型)。

MVVM和PM都来自MVC模式。

MVVM由微软架构师Ken Cooper和Ted Peters开发,通过利用WPF(微软.NET图形系统)和Silverlight(WPF的互联网应用派生品)的特性来简化用户界面的事件驱动程序设计。微软的WPF和Silverlight架构师之一John Gossman于2005年在他的博客上发表了MVVM。

MVVM也被称为model-view-binder,特别是在不涉及.NET平台的实现中。ZK(Java写的一个Web应用框架)和KnockoutJS(一个JavaScript库)使用model-view-binder。

  • MVVM模式的组成部分

    • 模型

      模型是指代表真实状态内容的领域模型(面向对象),或指代表内容的数据访问层(以数据为中心)。

    • 视图

      就像在MVC和MVP模式中一样,视图是用户在屏幕上看到的结构、布局和外观(UI)。

    • 视图模型

      视图模型是暴露公共属性和命令的视图的抽象。MVVM没有MVC模式的控制器,也没有MVP模式的presenter,有的是一个绑定器。在视图模型中,绑定器在视图和数据绑定器之间进行通信。

    • 绑定器

      声明性数据和命令绑定隐含在MVVM模式中。在Microsoft解决方案堆中,绑定器是一种名为XAML的标记语言。绑定器使开发人员免于被迫编写样板式逻辑来同步视图模型和视图。在微软的堆之外实现时,声明性数据绑定技术的出现是实现该模式的一个关键因素。

  • 理论基础

MVVM旨在利用WPF中的数据绑定函数,通过从视图层中几乎删除所有GUI代码(代码隐藏),更好地促进视图层开发与模式其余部分的分离。不需要用户体验(UX)开发人员编写GUI代码,他们可以使用框架标记语言(如XAML),并创建到应用程序开发人员编写和维护的视图模型的数据绑定。角色的分离使得交互设计师可以专注于用户体验需求,而不是对业务逻辑进行编程。这样,应用程序的层次可以在多个工作流中进行开发以提高生产力。即使一个开发人员在整个代码库上工作,视图与模型的适当分离也会更加高效,因为基于最终用户反馈,用户界面通常在开发周期中经常发生变化,而且处于开发周期后期。

MVVM模式试图获得MVC提供的功能性开发分离的两个优点,同时利用数据绑定的优势和通过绑定数据的框架尽可能接近纯应用程序模型。它使用绑定器、视图模型和任何业务层的数据检查功能来验证传入的数据。结果是模型和框架驱动尽可能多的操作,消除或最小化直接操纵视图的应用程序逻辑(如代码隐藏)。

MVVM 特点

在说MVVM之前,简单回顾一下MVP分层,MVP总共分成三层:

本节参考自 https://juejin.im/post/58cf2d791b69e6006b851605

  • a 、View: 视图层,对应xml文件与Activity/Fragment;
  • b 、Presenter: 逻辑控制层,同时持有View和Model对象;
  • c 、Model: 实体层,负责获取实体数据。

    logo

MVP模式有其很大的优点:

  • 1.解耦合,业务逻辑和视图分离;

  • 2.项目代码结构(文件夹)清晰,一看就知道什么类干什么事情;

  • 3.便于单元测试(其实还是第一点);

  • 4.协同工作(例如在设计师没出图之前可以先写一些业务逻辑代码或者其他人接手代码改起来比较容易);

但是也有美中不足的部分,MVP模式的缺点如下:

  • 1.Presente层与View层是通过接口进行交互的,接口粒度不好控制。粒度太小,就会存在大量接口的情况,使代码太过碎版化;粒度太大,解耦效果不好。因为View定义的方法并不一定全部要用到,可能只是后面要用到先定义出来(后面要不要删也未知),而且如果后面有些方法要删改,Presenter和Activity都要删改,比较麻烦;

  • 2.V层与P层还是有一定的耦合度。一旦V层某个UI元素更改,那么对应的接口就必须得改,数据如何映射到UI上、事件监听接口这些都需要转变,牵一发而动全身。如果这一层也能解耦就更好了。

  • 3.复杂的业务同时也可能会导致P层太大,代码臃肿的问题依然不能解决,这已经不是接口粒度把控的问题了,一旦业务逻辑越来越多,View定义的方法越来越多,会造成Activity和Fragment实现的方法越来越多,依然臃肿。

MVVM 的优点

View和Model进行了双向绑定,两者之间有一方发生变化则会反应在另一方

MVP和MVC的主要区别是,MVP的View不能直接访问Model,需要通过Presenter发送请求,View和Model 不能直接通信。

MVP和MVVM的主要区别是,MVP 的View更新需要通过Presenter,而MVVM不需要,因为View 和
Model进行了双向绑定,数据的修改会直接反应在View上,而View的修改也会导致数据变更
,此时ViewModel需要做的是业务逻辑处理,以及修改View和Model的状态

原文:https://blog.csdn.net/Ghost_tal/article/details/82052377

MVVM & LiveData

使用 LiveData 的好处

  • UI 和数据保持一致性

    LiveData 遵循观察者模式。Observer 生命周期状态更改时,LiveData 会通知其观察的对象列表。每次应用程序数据更改时,观察者都可以在每次更改时收到消息并更新UI,而不是主动去获取状态来更新UI。

  • 没有内存泄漏

    观察者绑定 Lifecycle 对象并在其相关生命周期被销毁后自行清理。

  • 不会因 UI 暂停而崩溃

    如果观察者的生命周期处于非活动(例如,在后台堆栈中的 Activity 的情况下),则它不会接收任何 LiveData 事件。

  • 不再需要手动管理生命周期

    UI组件只是观察相关数据,不会停止或恢复观察。LiveData 自动管理所有这些动作,因为它可以感知到到相关的生命周期状态变化。

  • 始终保持最新数据

    如果 UI 生命周期变为非活动,它将在再次变为活动时接收最新数据。例如,后台 Activity 在返回前台后立即接收最新数据。

  • 配置更改自动处理

    如果由于配置更改(例如设备旋转)而重新创建 Activity 或 Fragment ,则会立即接收最新的可用数据。

  • 共享资源

    您可以把 LiveData 使用单例模式来包装各种系统服务,以便可以在应用程序中共享它们。该 LiveData 对象连接到系统服务一次,然后任何需要该资源的观察者只需观察该 LiveData 对象,即可拿到共享的数据资源。

MVVM 每一层的处理

Model

show me the code as flowing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class MainRepository : BaseRepository() {


val loadSuccess = MutableLiveData<FirstCategoryResp>()

fun loadData() {
compositeDisposable.add(Flowable.just(Any())
.doOnNext { showLoading() }
.subscribeOn(Schedulers.io())
.flatMap { WebApiService.getFirstCategories(FirstCategoryReq()) }
.doOnNext { loadSuccess.postValue(it) }
.doFinally { dismissLoading() }
.subscribe({ }, { throwable -> LogUtils.e(throwable, "获取一级分类信息失败") })
)
}
}

如上所示: Repository 持有 WebApiService, 同时,持有需要发射的后台数据。比如进行网络请求,数据库操作等。

ViewModel

1
2
3
4
5
6
7
8
9
10
11
class MainViewModel : BaseViewModel<MainRepository>() {
override fun initRepo(): MainRepository {
return MainRepository()
}

val loadSuccess: LiveData<FirstCategoryResp> = Transformations.map(repository.loadSuccess) { it }

fun loadData() {
repository.loadData()
}
}

ViewModel 持有需要发射的 LiveData 数据对象,这里比较特殊,通过 Transformations.map 直接转发来发射自 Repository 的数据 ,同时提供加载数据的方法给 View 调用。方法内部没有任何逻辑,直接转发调用 Repository 的方法进行数据加载。

View

1
2
3
override fun initLiveDataObserver() {
viewModel.loadSuccess.observe(this, androidx.lifecycle.Observer { refreshUI(it) })
}

在 View 层,持有 ViewModel,并观察 ViewMode 的数据变化。当有新的数据发射出来时,直接调用更新 UI。

综上,可以看出,从 View -> ViewModel -> Repository,即代表了 V -> VM -> M 这样的单向引用。统一标准为上层直接依赖下层,上传简介观察下层的数据变化,并非下层调用上层的业务逻辑,每一层之间的数据转发都是通过观察者的模式来连接。

Repository 结合 RxJava 使用

在上面的示例中,已经展示过在 Repository 里使用 RxJava 进行网络请求的流封装,并且在 BaseViewModel 的 onCleared 方法中,调用 CompositeDisable 的 clear 方法进行后台任务的取消和清除。

而且可以看到,在进行网络数据请求或者任何耗时操作的时候,不需要进行主动的线程切换,因为所有的数据发射,我们都是使用了 postValue 方法,在其内部已经帮我们进行了现场的切换。

LiveData & RxJava 比较

两者有很多相似的地方,但是侧重点有所不同。

  • LiveData 侧重于生命周期的管理。

  • RxJava 侧重于流式 API 的支持。

总结

总体来说,MVVM 是非常值得一试的。就目前的使用情况来看,没发现什么严重的问题。推荐一试。当然,任何东西也都不可能是完美的,始终要抱着辩证的思维去看待一个事情,但是也要保持积极地心态去拥抱新技术的不断涌现,才不至于被潮流所抛弃。

-------------本文结束感谢您的阅读-------------
坚持原创技术分享,您的支持将鼓励我继续创作!