Android 设计模式对比

引言:

Android框架的发展的过程就是一个不断化繁为简的过程,大家都在研究如何正确方便高效的规范代码。当然这条路也永远不会停止,就像新的芽儿,随着时间的流逝,每天都在长出新的枝叶,每天都在成长。对于技术,每次新框架的提出都在剔除旧框架的诟病和痛点,演变成更方便,更高效,更简洁的新框架,然后新的框架在具体使用中又会带来新的诟病和痛点,反反复复,无穷尽也......从开始使用MVC到使用MVP,从MVP到MVVM,每次框架的提出都有让我们眼前一亮的东西,但具体使用中确还是存在很多的痛点,似乎一直存在一种反作用力来阻止我这样做。但又能怎样?新的芽儿注定会长成参天大树,技术终究只会进步。

概述

MVC

MVC这里就不多说了,大家都熟悉的不能再熟悉了,比较古老的框架了,相信大家也都使用过;

MVC具体使用

  • Model:数据模型,JavaBean
  • View:layout布局文件
  • Control:Activity,处理数据请求,业务逻辑

MVC的诟病

  • View和Control耦合严重,Activity中存在大量的逻辑代码,Activity既是View,又是Control,结构不清晰,Activity中内容太多

MVP

MVP是在MVC的基础上把Control独立出来的模型,简化Control的内容,这里Presenter充当中间代理的角色,view和Model不直接交互,而是通过Presenter

MVP的具体使用

  • Model:实体模型,JavaBean
  • View:Activity和Layout
  • Presenter:View和Model通过Presenter交互

MVP的诟病

  • 粒度很难把握,使用过MVP的都知道,MVP模型需要定义比较多的接口,View需要定义接口,presenter需要定义接口,以前我们使用一个activty能解决的问题,现在要将一个Activity分解成一个View,一个Preseter,一个Model,每个模块都需要使用接口来实现解耦,这样就会导致有时候一个activity中涉及的业务比较多,按每个业务点搭建MVP模型的话,会导致原来一个Activity类能搞定的,现在需要扩展成多个接口,多个类才能实现;粒度大的话,可能结构不清晰;粒度小的话,代码量又会比较大;
  • MVP是以UI和事件为驱动的模型,数据的获取是被动的根据UI变动的,我们更希望是数据变化去更新UI,而不是反过来;
  • Presenter和View耦合度比较高;
  • Presenter类在业务比较复杂情况下,代码量比较大;

MVVM

MVVM是在MVP的基础上,根据谷歌提出的DateBinding方案重新设计的一个灵活高效的框架,MVVM使用ViewModel一层代替原来的Presenter层;

MVVM的使用

  • Model:数据模型,JavaBean
  • View:Activty和Layout
  • ViewModel:View和Model业务逻辑交互

MVVM的优点

数据驱动

在MVVM中,数据的变化可以自动更新view,不需要获取view的引用;

耦合较低

MVP模式中View和Presenter是强耦合的,Presenter需要拿到View的引用,这样当View变动时,Presenter也需要变化,耦合度太高;现在MVVM中,ViewModel只负责数据和业务,View的变化,ViewModel不需要关系,数据变化,View自动更新,耦合度比较低;

View更新

MVVM模型中不用考虑是否在主线程中更新UI,DateBinding会负责在主线程中更新UI的,我们不用担心线程的问题,简单的不止一点点;

可重复利用

一个ViewModel就是一个数据源,可以将一个ViewModel绑定到不同的View中,就可以达到更新view目的

MVVM的诟病

  • MVVM由于是基于google的DataBinding框架的,而DataBinding支持的绑定View还比较少,因此在使用的过程中可能会遇到某些view无法使用DateBinding的情况,这点也是我之前没有使用MVVM的原因
  • 既然存在上面的问题,国内外的大牛已经帮我们封装好了一套使用dateBinding的view库,为避免重复造轮子,我们可以将它引入到我们的项目中直接使用,目前我知道的已经支持常用所有View;

总结

经过上面对不同框架的对比,相信大家都有一个基本的了解,有人会问这么多框架,我们使用那个比较好呢?

个人觉得,技术是在不断进步,旧的框架最终都会被新的框架所代替,我觉得MVVM的提出解决了我们使用其他框架的很多痛点,我觉得使用MVVM会更好点。

时间: 2024-10-07 10:49:09

Android 设计模式对比的相关文章

java/android 设计模式学习笔记(14)---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

java/android 设计模式学习笔记(7)---装饰者模式

这篇将会介绍装饰者模式(Decorator Pattern),装饰者模式也称为包装模式(Wrapper Pattern),结构型模式之一,其使用一种对客户端透明的方式来动态的扩展对象的功能,同时它也是继承关系的一种替代方案之一,但比继承更加灵活.在现实生活中也可以看到很多装饰者模式的例子,或者可以大胆的说装饰者模式无处不在,就拿一件东西来说,可以给它披上无数层不一样的外壳,但是这件东西还是这件东西,外壳不过是用来扩展这个东西的功能而已,这就是装饰者模式,装饰者的这个角色也许各不相同但是被装饰的对

java/android 设计模式学习笔记(13)---享元模式

这篇我们来介绍一下享元模式(Flyweight Pattern),Flyweight 代表轻量级的意思,享元模式是对象池的一种实现.享元模式用来尽可能减少内存使用量,它适合用于可能存在大量重复对象的场景,缓存可共享的对象,来达到对象共享和避免创建过多对象的效果,这样一来就可以提升性能,避免内存移除和频繁 GC 等. 享元模式的一个经典使用案例是文本系统中图形显示所用的数据结构,一个文本系统能够显示的字符种类就是那么几十上百个,那么就定义这么些基础字符对象,存储每个字符的显示外形和其他的格式化数据

java/android 设计模式学习笔记(12)---组合模式

这篇我们来介绍一下组合模式(Composite Pattern),它也称为部分整体模式(Part-Whole Pattern),结构型模式之一.组合模式比较简单,它将一组相似的对象看作一个对象处理,并根据一个树状结构来组合对象,然后提供一个统一的方法去访问相应的对象,以此忽略掉对象与对象集合之间的差别.这个最典型的例子就是数据结构中的树了,如果一个节点有子节点,那么它就是枝干节点,如果没有子节点,那么它就是叶子节点,那么怎么把枝干节点和叶子节点统一当作一种对象处理呢?这就需要用到组合模式了. 转

java/android 设计模式学习笔记(9)---代理模式

这篇博客我们来介绍一下代理模式(Proxy Pattern),代理模式也成为委托模式,是一个非常重要的设计模式,不少设计模式也都会有代理模式的影子.代理在我们日常生活中也很常见,比如上网时连接的代理服务器地址,更比如我们平时租房子,将找房子的过程代理给中介等等,都是代理模式在日常生活中的使用例子. 代理模式中的代理对象能够连接任何事物:一个网络连接,一个占用很多内存的大对象,一个文件,或者是一些复制起来代价很高甚至根本不可能复制的一些资源.总之,代理是一个由客户端调用去访问幕后真正服务的包装对象

java/android 设计模式学习笔记(6)---适配器模式

这篇来介绍一下适配器模式(Adapter Pattern),适配器模式在开发中使用的频率也是很高的,像 ListView 和 RecyclerView 的 Adapter 等都是使用的适配器模式.在我们的实际生活中也有很多类似于适配器的例子,比如香港的插座和大陆的插座就是两种格式的,为了能够成功适配,一般会在中间加上一个电源适配器,形如: 这样就能够将原来不符合的现有系统和目标系统通过适配器成功连接. 说到底,适配器模式是将原来不兼容的两个类融合在一起,它有点类似于粘合剂,将不同的东西通过一种转

java/android 设计模式学习笔记(3)---工厂方法模式

这篇来介绍一下工厂方法模式(Factory Method Pattern),在实际开发过程中我们都习惯于直接使用 new 关键字用来创建一个对象,可是有时候对象的创造需要一系列的步骤:你可能需要计算或取得对象的初始设置:选择生成哪个子对象实例:或在生成你需要的对象之前必须先生成一些辅助功能的对象,这个时候就需要了解该对象创建的细节,也就是说使用的地方与该对象的实现耦合在了一起,不利于扩展,为了解决这个问题就需要用到我们的工厂方法模式,它适合那些创建复杂的对象的场景,工厂方法模式也是一个使用频率很

java/android 设计模式学习笔记(2)---观察者模式

这篇来讲一下观察者模式,观察者模式在实际项目中使用的也是非常频繁的,它最常用的地方是GUI系统.订阅--发布系统等.因为这个模式的一个重要作用就是解耦,使得它们之间的依赖性更小,甚至做到毫无依赖.以GUI系统来说,应用的UI具有易变性,尤其是前期随着业务的改变或者产品的需求修改,应用界面也经常性变化,但是业务逻辑基本变化不大,此时,GUI系统需要一套机制来应对这种情况,使得UI层与具体的业务逻辑解耦,观察者模式此时就派上用场了. PS:对技术感兴趣的同鞋加群544645972一起交流. 设计模式

java/android 设计模式学习笔记(4)---抽象工厂模式

再来介绍一下抽象工厂模式(Abstact Factory Pattern),也是创建型模式之一,上篇博客主要介绍了工厂方法模式.抽象工厂模式和工厂方法模式稍有区别.工厂方法模式中工厂类生产出来的产品都是具体的,也就是说每个工厂都会生产某一种具体的产品,但是如果工厂类中所生产出来的产品是多种多样的,工厂方法模式也就不再适用了,就要使用抽象工厂模式了. 抽象工厂模式的起源或者最早的应用,是对不同操作系统的图形化解决方案,比如在不同操作系统中的按钮和文字框的不同处理,展示效果也不一样,对于每一个操作系