前言

  本文属于《Android构建MVVM》系列开篇,共六个篇章,详见目录树。

  该系列文章旨在为Android的开发者入门MVVM架构,掌握其基本开发模式。

  辅以讲解Android Architecture Components,使得更好的实现MVVM架构。

目录树

  • 《Android构建MVVM》系列(一) 之 MVVM架构快速入门

    • 前言
    • 分层思想
    • 什么是MVC/MVP?
    • MVVM是什么,与MVC/MVP有何区别?
    • Android Architecture Components(架构组件)
    • 一个MVVM的Demo
    • 结语
  • 《Android构建MVVM》系列(二) 之 架构组件LiveData
  • 《Android构建MVVM》系列(三) 之 架构组件ViewModel
  • 《Android构建MVVM》系列(四) 之 架构组件Room
  • 《Android构建MVVM》系列(五) 之 构建更好的Demo
  • 《Android构建MVVM》系列(六) 之 总结与展望

正文

一、分层思想

  层是一种思想,同时也是一种架构模式。它的特点是专职,即某一层的职责是相同的、确定的;比如我们平时所谓的Dao、Controller层…他们都有明确的职责。

  分层思想具体表现为,通过抽象某一类的逻辑构成一个水平功能面,进而对上层提供API;多个层面相互依赖、配合提供整体解决方案。层与层之间的依赖关系是自上而下的,即上层依赖下层,下层不能依赖上层,最底层的组件没有依赖。

  初学者往往搞不明白为什么明明可以直接编码业务逻辑,还要去做所谓的分层架构呢?

    其实对仅仅实现需求来说,用不用分层架构没有关系的,不分层照样可以实现;那么为什么我们还要徒增烦恼呢?有句话说的好:“存在即合理”,也就是说既然我们的前辈研究出了所谓的分层架构,并且沿用至今;那么就一定有它的优点,一定是解决了某一领域的痛点而诞生的

    试想以下场景:当你的项目随着需求的增加和不断调整,不可避免的就要去改动已有的代码,如果项目规模不大还好,如果是个老古董项目,可能某个类里面上万行的代码,没有注释,没有采用分层架构,相信我,你会哭的

  分层架构虽说不能完完全全的解决项目程序复杂度高的问题,但是通过分层,将大的问题抽象分解成了小的功能面,局部化在每一层中,这样就有效的降低了单个问题的规模和复杂度;另外层与层之间也可以通过简单的调整,插入新的层面,用以满足不断变化的需求,同一层面来说也可近乎0成本的水平扩展;并且易于后期的Debug、测试。

二、什么是MVC/MVP?

  来说说MVC吧,其实MVX模式都是分层思想的一种具体实现,上文提到的分层思想实际上是一种抽象层面的分层,着重表现在抽象和解耦。

  MVC实际上是一种分层思想的践行者和改进者,在GUI编程中,MVC已经有几十年的历史了。

    顾名思义M(Model)即数据模型层,Model层很有意思,对于服务端编程来说我们把MVC中的M极有可能是包括了业务处理(Service)和实体类的,对于客户端编程来说MVC中的M可能就仅仅是数据模型,当然以上的说法只是于我个人而言的体会,不代表广义立场。

  V(View)即视图层/表现层,主要负责数据的展示和用户的交互,C(Controller)即控制层,主要负责一些数据传递、请求转发、业务处理的委派。

  以上是标准意义上的MVC,对于Android来说:

Model:数据模型(实体类、持久化、IO)
View:布局文件
Controller:对应于Activity、Fragment,包含一些业务逻辑的处理

  这里我们会发现,Android的MVC事实上V层的职责一部分被C层承担了,比如一些Activity/Fragment中不可避免的一些交互逻辑等,这样就会导致C层既包含UI交互,又有网络请求、业务处理等;导致C层过于臃肿,不利于项目后期的维护和扩展。

  所以,MVP就应运而生了,MVP实际上是由MVC进化而来,它比较好的解决了MVC时代遗留的问题,MVP中的各层含义:

Model:数据模型(实体类、持久化、IO)
View:Activity/Fragment和布局文件
Presenter:负责完成View和Model之间的交互和业务逻辑

  其核心思想是:设计一个抽象的V层接口,并由具体的View实现该接口,P层内部维护一个该接口的实例引用,一般在构造函数中传递进来赋值(即View层初始化P层实例时),彼时P层即可通过调用该接口来完成对View层的操作,V层也因持有P层实例,可以进行业务逻辑处理委派。

三、MVVM是什么?与MVC/MVP有何区别?

  MVVM是对MVP/MVC的一种改进,既解决了MVC时代的职责不明的问题,也很好的解决了MVP模式中需要编写过多繁琐的接口,以及V层和P层互相依赖所产生的一些隐式问题。

  在MVVM中,各层含义如下:

Model:数据模型(实体类、持久化、IO)
View:Activity/Fragment和布局文件
ViewModel:业务逻辑的处理、数据的转换、连接M层和V层的桥梁

  看上去似乎和MVP中各层的职责是类似的,并没有显著的不同和改进;那么我们为何要使用MVVM架构呢?

  引入美团技术团队的一段解释

    1. 双向绑定、数据驱动
      在常规的开发模式中,数据变化需要更新UI的时候,需要先获取UI控件的引用,然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中,这些都是通过数据驱动来自动完成的,数据变化后会自动更新UI,UI的改变也能自动反馈到数据层,数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据,不需要直接和UI打交道,在业务处理过程中简单方便很多。

    2. 高度解耦
      MVVM模式中,数据是独立于UI的。
      数据和业务逻辑处于一个独立的ViewModel中,ViewModel只需要关注数据和业务逻辑,不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定,ViewModel不涉及任何和UI相关的事,也不持有UI控件的引用。即便是控件改变了(比如:TextView换成EditText),ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel,解决了上面我们所说的MVP的痛点。

    3. 可复用、易测试、方便协同开发
      一个ViewModel可以复用到多个View中。同样的一份数据,可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动,更新或新增一套View即可。如果想在UI上做A/B Testing,那MVVM是你不二选择。
      MVVM的分工是非常明显的,由于View和ViewModel之间是松散耦合的:一个是处理业务和数据、一个是专门的UI处理。所以,完全由两个人分工来做,一个做UI(XML和Activity)一个写ViewModel,效率更高
      ViewModel层做的事是数据处理和业务逻辑,View层中关注的是UI,两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试,都是低耦合的。在MVVM中数据是直接绑定到UI控件上(部分数据是可以直接反映出UI上的内容),那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。

四、Android Architecture Components(架构组件)

  现MVVM的方式和工具有很多,既可以使用Google在2015年推出的DataBinding库,亦或是其他。也可以选择Google IO 2017 推出的Android Architecture Components即架构组件,亦或是其他方式。

  本文采用的解决方案:使用Architecture Components架构MVVM。

  上图是官方给出的架构模型,包含以下组件:

  • 生命周期管理库 – Lifecycle

    • Lifecycle组件,为下面两个组件提供了生命周期感知的基础

    • LiveData组件,可观测的、可感知生命周期的数据

    • ViewModel组件,不依赖于View、提供UI数据、桥接持久层、业务逻辑

  • 数据持久化库 – Room,Sqlite的ORM

   事实上,Architecture Components实现了一个比较理想化的依赖方式,自上而下,单向依赖;VM层并不持有View层的任何引用,但却是生命周期感知的,在新版的AS中View也不用去实现某些接口或继承特定的类,AppCompatActivity已经帮你整合了这一切。

  另外,关于Repository的解释,它并不是架构组件的成员,但是Google推荐引入Repository层,来作为我们唯一的数据来源接口,我们从图中也很好理解,他的职责就是使VM层对数据来源是无感知的,包装了数据来源,提供统一的API,供上层透明化的调用。

  更多的关于Android Architecture Components的教程,欢迎关注我们后续的架构组件篇章。

五、一个MVVM的Demo

  面我们通过设计App《每日美文》的Demo,并使用Architecture Components架构MVVM的方式去完成。

  这个Demo使用Kotlin开发,没接触过Kotlin的童鞋也不必担心,本文没有用到Kotlin的一些高级特性,只需要Google花个半小时时间学习基本的Kotlin语法便可无障碍阅读

  项目地址:https://github.com/xykjlcx/OneArticleDemo

1. 首先我们创建工程

 

项目创建完成后的目录结构

架构组件的相关依赖

// livedata viewmodel
    def lifecycle_version = "1.1.1"
    implementation "android.arch.lifecycle:extensions:$lifecycle_version"
    implementation "android.arch.lifecycle:viewmodel:$lifecycle_version"
    implementation "android.arch.lifecycle:livedata:$lifecycle_version"
    implementation "android.arch.lifecycle:runtime:$lifecycle_version"
    annotationProcessor "android.arch.lifecycle:compiler:$lifecycle_version"

  PS:视图(布局xml)就不带大家看了,很简单,有兴趣的童鞋可以直接到Github上看源码

2. 工具类:OceanUtil

  网络请求封装的有些随意,轻喷

版权声明:本文为xykjlcx原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/xykjlcx/p/9469690.html