开发模式进阶

常见的开发模式

MVP

MVP也就是model-view-presenter模式。由presenter来连接model和view之间的联系,并且进行view里面的逻辑操作。好处是使得view更加简洁,逻辑清楚易于维护。

缺点是

  • 大量引入类,开发者可能不能辨别三层的具体分工导致无法解耦。
  • MVP以UI和事件为驱动,数据被动的通过UI来展示,但是数据的时变性,我们希望数据能转被动为主动,由数据来推动UI。
  • 一旦V层某个UI元素更改,那么对应的接口和事件监听都得改。

下面分析google的mvp项目

todo-mvp

google Mvp架构

技术亮点:
1.xml属性:parentActivityName:指定activity的父activity,系统会读取该属性,以确定当用户按下操作栏中的“向上”按钮时应该启动哪一个 Activity。 系统还可以利用这些信息通过 TaskStackBuilder 合成 Activity 的返回栈。

2.xml属性:noHistory:当用户离开 Activity 并且其在屏幕上不再可见时,是否应从 Activity 堆栈中将其移除并完成。当为true时onActivityResult无法取得数据。

MVVM

参考如何构建Android MVVM应用框架
具体角色与MVP相似,Presenter由ViewModel替换,Model的角色扩展了,添加了进行数据的获取,存储,数据状态变化的任务。MVVM的目标和思想与MVP类似,利用数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性,打造了一个更加灵活高效的架构。

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

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

更新UI
在MVVM中,数据发生变化后,我们在工作线程直接修改(在数据是线程安全的情况下)ViewModel的数据即可,不用再考虑要切到主线程更新UI了,这些事情相关框架都帮我们做了。

可复用性
一个ViewModel可以复用到多个View中。同样的一份数据,可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动,更新或新增一套View即可。如果想在UI上做A/B Testing,那MVVM是你不二选择。

架构:

ViewModel与View协作
ViewModel和View是通过绑定的方式连接在一起的,绑定分成两种:一种是数据绑定,一种是命令绑定。数据的绑定DataBinding已经提供好了,简单地定义一些ObservableField就能把数据和控件绑定在一起了。我们看ViewModel的结构:

  • Context:用于网络判断生命周期,防止请求回来时Activity已经销毁及工具类等
  • Model:其实就是Java Bean,可以用来生成对应的ObservableField。这是肯定需要持有的。
  • Data Field(数据绑定):需要绑定到控件上的ObservableField字段。
  • Command(命令绑定):对事件的处理,比如下拉,加载,点击等。存在的问题是如果不使用三方库可能需要持有View的引用,等会需要特别注意一下这里。使用DataBinding就可以在xml中绑定View的处理命令
  • Child ViewModel:子vm,比如一个Activity由两个Fragment,这样就可以有两个子vm

ViewModel与Model协作
ViewModel通过传参数到Model层获取网络数据(数据库同理),然后把Model的部分数据映射到ViewModel的一些字段(ObservableField),并在ViewModel保留这个Model的引用

ViewModel与ViewModel的协作
用Messenger来在ViewModel中进行通讯。

Clean-Architecture

基本思想:

项目架构:

Presenter层可以使用MVP或MVVM模式,Data Layer负责获取数据,不管是数据库还是磁盘,网络都是用这层来处理。Domain layer负责处理使用场景,也就是负责处理逻辑。相当于Presenter层的Presenter需要依赖Domain layer才能真正处理逻辑。