android mvvm框架（android 怎么使用mvvm框架）

本文目录

• android 怎么使用mvvm框架
• 有没有比较成熟的Android开源MVC框架
• 为什么Android MVVM框架没有流行开
• 怎么样能快速搭建一个Android APP的界面和框架
• android viewmodel怎么用
• android mvp mvvm怎么选择 简书
• android mvvm怎么更新数据

android 怎么使用mvvm框架

MVC、MVP、MVVM
首先，我们先大致了解下Android开发中常见的模式。
MVC
View：XML布局文件。
Model：实体模型（数据的获取、存储、数据状态变化）。
Controllor：对应于Activity，处理数据、业务和UI。
从上面这个结构来看，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色，直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧！所以，更贴切的说法是，这个MVC结构最终其实只是一个Model-View（Activity:View&Controller）的结构。
MVP
View:对应于Activity和XML，负责View的绘制以及与用户的交互。
Model:依然是实体模型。
Presenter:负责完成View与Model间的交互和业务逻辑。
前面我们说，Activity充当了View和Controller两个角色，MVP就能很好地解决这个问题，其核心理念是通过一个抽象的View接口（不是真正的View层）将Presenter与真正的View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而让Activity成为真正的View层。
但MVP也存在一些弊端：
Presenter（以下简称P）层与View（以下简称V）层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化；粒度太大，解耦效果不好。同时对于UI的输入和数据的变化，需要手动调用V层或者P层相关的接口，相对来说缺乏自动性、监听性。如果数据的变化能自动响应到UI、UI的输入能自动更新到数据，那该多好！
MVP是以UI为驱动的模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候要考虑当前是否是UI线程，也要考虑Activity的生命周期（是否已经销毁等）。
MVP是以UI和事件为驱动的传统模型，数据都是被动地通过UI控件做展示，但是由于数据的时变性，我们更希望数据能转被动为主动，希望数据能更有活性，由数据来驱动UI。
V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变，牵一发而动全身。如果这一层也能解耦就更好了。
复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决。
MVVM
View:对应于Activity和XML，负责View的绘制以及与用户交互。
Model:实体模型。
ViewModel:负责完成View与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了，这些事情相关框架都帮我们做了。
团队协作
MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的：一个是处理业务和数据、一个是专门的UI处理。所以，完全由两个人分工来做，一个做UI（XML和Activity）一个写ViewModel，效率更高。
可复用性
一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。
单元测试
有些同学一看到单元测试，可能脑袋都大。是啊，写成一团浆糊的代码怎么可能做单元测试？如果你们以代码太烂无法写单元测试而逃避，那可真是不好的消息了。这时候，你需要MVVM来拯救。
我们前面说过了，ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的（部分数据是可以直接反映出UI上的内容），那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。
通过上面的简述以及模式的对比，我们可以发现MVVM的优势还是非常明显的。虽然目前Android开发中可能真正在使用MVVM的很少，但是值得我们去做一些探讨和调研。
如何构建MVVM应用框架
如何分工
构建MVVM框架首先要具体了解各个模块的分工。接下来我们来讲解View、ViewModel、Model它们各自的职责所在。
View
View层做的就是和UI相关的工作，我们只在XML、Activity和Fragment写View层的代码，View层不做和业务相关的事，也就是我们在Activity不写业务逻辑和业务数据相关的代码，更新UI通过数据绑定实现，尽量在ViewModel里面做（更新绑定的数据源即可），Activity要做的事就是初始化一些控件（如控件的颜色，添加RecyclerView的分割线），View层可以提供更新UI的接口（但是我们更倾向所有的UI元素都是通过数据来驱动更改UI），View层可以处理事件（但是我们更希望UI事件通过Command来绑定）。 简单地说：View层不做任何业务逻辑、不涉及操作数据、不处理数据，UI和数据严格的分开。
ViewModel
ViewModel层做的事情刚好和View层相反，ViewModel只做和业务逻辑和业务数据相关的事，不做任何和UI相关的事情，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理，做的事情也都只是对数据的操作（这些数据绑定在相应的控件上会自动去更改UI）。同时DataBinding框架已经支持双向绑定，让我们可以通过双向绑定获取View层反馈给ViewModel层的数据，并对这些数据上进行操作。关于对UI控件事件的处理，我们也希望能把这些事件处理绑定到控件上，并把这些事件的处理统一化，为此我们通过BindingAdapter对一些常用的事件做了封装，把一个个事件封装成一个个Command，对于每个事件我们用一个ReplyCommand 去处理就行了，ReplyCommand 会把你可能需要的数据带给你，这使得我们在Vie，具体见 MVVM Light Toolkit 使用指南的 Command 部分 。再强调一遍：ViewModel 不做和UI相关的事。

有没有比较成熟的Android开源MVC框架

Android的MVC框架有不少，但是不能成为主流。
Android开发并不像企业及JAVA一样有主流的SSH，
毕竟企业JAVA 是WEB开发，而Android是客户端开发，客户端的代码别人是可以进行破解反编译的。
一般经理的要求是，框架写得越复杂。让别人反编译越难越好。
若大家都采用统一的MVC框架，那客户端的代码安全性就降低了。

为什么Android MVVM框架没有流行开

快，比如我要做一个列表，要求上拉刷新，下来加载你自己搞，一星期不见得搞得定，并且bug满天飞但是你可以去github上下载一个开源的库，几分钟功能就完成了。虽然不知道人家是如何实现的，但是至少你完成了你的功能

怎么样能快速搭建一个Android APP的界面和框架

自己从零开始快速搭建Android app架构

简单的看下这三个架构模式：

MVC：Model-View-Controller，经典模式，很容易理解，主要缺点有两个：
View对Model的依赖，会导致View也包含了业务逻辑；
Controller会变得很厚很复杂。

MVP：Model-View-Presenter，MVC的一个演变模式，将Controller换成了Presenter，主要为了解决上述第一个缺点，将View和Model解耦，不过第二个缺点依然没有解决。

MVVM：Model-View-ViewModel，是对MVP的一个优化模式，采用了双向绑定：View的变动，自动反映在ViewModel，反之亦然。

面对众多的架构模式你会选择哪个？

MVC，MVP还是MVVM？

越高级的模式复杂性越高，实现起来也越难。然后搭建项目时也是看项目的需求，别人说好你也有要实用才好，高效的实现项目的功能才是最好的架构模式。

那么，哪一个才是最好的呢？

个人觉得适合你的才是最好的，不要去盲目的跟风，大家说mvp好那你就使用咯，没有实践就没有话语权，所以说用哪种架构模式本人不发表任何意见：任何模式的动机都是一样的，那就是如何避免复杂混乱的代码，让执行单元测试变得容易，创造高质量应用程序，开发维护更高效。

在实际项目中思考架构时，也不会想着要用哪种模式，我只思考现阶段，以现有的人力资源和时间资源，如何才能更快更好地完成需求，适当考虑下如何为后期扩展或重构做准备。

我项目中的架构

这是我上一个项目的包架构：

当然咯，是按功能分的包，项目的功能不一样然后分包也不一样，但是基本大同小异。 

所以确定架构分包的时候那就按你的需求来咯。  

从上面可以看出：架构分包的时候我们包括逻辑功能和基础功能（通用功能）。  

基础功能模块：

日志管理系统（LogManager）

不管哪个项目都需要自己的一套日志管理，一是为了生产调试时能更加高效的查看过滤日志，二是为了打包发布的时候用开关控制日志是否打印。  （我的日志用的是凯子哥的：Klog）

异常处理(crashManager) 

作用：当程序遇见异常情况时我们能够自定义异常处理，二是程序对不同的机型有不同的反应，那么测试时候可能没有发现但是我们可以把捕获的crash上传到服务器，便于异常收集和bug修复。

utils(工具类)

根据你的项目需求来合理定制你的工具类，将会对你的项目开发速度有很大的提升（反馈，版本校验更新你肯定能够用到）

看下我上个项目的工具类：  

permission(权限管理系统) 

这功能是绝对项目中需要的，别告诉我你的项目还没有适配安卓6.0，适配了就肯定会有权限管理，我这里用的是 安卓6.0权限处理在项目中的实践,也还可以吧，反正github上的权限管理的开源东西比较多，觉得合适就ok。

哈哈，这样基础功能都搭建好了，然后就是一些逻辑功能的封装了。 

android viewmodel怎么用

何工
构建MVVM框架首先要具体解各模块工接我讲解ViewViewModelModel 各自职责所
View
View层做UI相关工作我XMLActivity或Fragment写View层代码View层做业务相关事我Activity 写业务逻辑相关代码写需要根据业务逻辑更新UI代码更新UI通Binding实现更新UIViewModel面做（更新绑定数据源即）Activity 要做事初始化些控件（控件颜色添加 RecyclerView 割线）Activity更新UI更新UI必须业务逻辑数据没关系单纯根据点击或者滑等事件更新UI( 根据滑颜色渐变、根据点击隐藏等单纯UI逻辑)Activity（View层）处理UI事件处理处理UI自事情View层处理View层事简单说：View层做任何业务逻辑、涉及操作数据、处理数据、UI数据严格
ViewModel
ViewModel层做事情刚View层相反ViewModel 做业务逻辑业务数据相关事做任何UI、控件相关事ViewModel 层持任何控件引用更ViewModel通UI控件引用做更新UI事情ViewModel专注于业务逻辑处理操作都数据进行操作些数据源绑定相应控件自更改UI发者需要关更新UI事情DataBinding 框架已经支持双向绑定使我通双向绑定获取View层反馈给ViewModel层数据并进行操作关于UI控件事件处理我希望能些事件处理绑定控件并些事件统化便ViewModel事件处理代码美观我通BindingAdapter 些用事件做封装事件封装Command于每事件我用ReplyCommand处理行,ReplyCommand能需要数据带给使我处理事件候关处理数据行具体见MVVM Light Toolkit 使用指南 Command 部再强调遍ViewModel 做UI相关事
Model
Model 职责简单基本实体模型（Bean）同包括Retrofit Service ViewModel 根据Model 获取BeanObservable( RxJava ),做些数据转换操作映射ViewModel 些字段些字段绑定View层
总说ViewModel View 前仅仅绑定关系View层需要属性事件处理都xml面绑定ViewModel层操作UI操作数据ViewModel根据业务要求处理数据些数据自映射View层控件属性关于ViewModel类包含哪些模块字段需要发者自衡量边建议ViewModel 要引入太员变量员变量面提5种（context、model、…）能进入其类型变量尽量要引进太员变量于整代码结构破坏面维护要刻关员变量候初始化候清掉候赋值或者改变细节能现潜Bug太清晰定义员变量没注释代码难维护
Model 通Retrofit 获取网络数据返数据Observable( RxJava ),Model 层其实做些ViewModel 做通传参数Model层获取网络数据（数据库同理）Model部数据映射ViewModel些字段（ObservableField）并ViewModel 保留Model引用,我看块致代码(代码涉及简单RxJava看懂查阅入门.
-

android mvp mvvm怎么选择 简书

1.MVC
传统的Android App其实都是基于MVC的，Activity，Fragment相当于C,布局相当于V,数据逻辑相当于M
随着业务的增长Controller里的代码会越来越臃肿，因为它不只要负责业务逻辑，还要控制View的展示。也就是说Activity、Fragment杂糅了Controller和View，耦合变大。并不能算作真正意义上的MVC。
这也是为什么后面的MVP会引起很多开发者兴趣的原因了。
2.MVP
MVP架构其实可以说与MVC的架构还是有很大的差别的，数据逻辑相当于M，Activity（负责View的绘制以及与用户交互）相当于V ，View于Model间的交互则为P
理论上感觉区别有点抽象，可以通过下面的图来看一看其中的区别

android mvvm怎么更新数据

可以使用框架,参考内容如下:1、概述Databinding是一种框架，MVVM是一种模式，两者的概念是不一样的。我的理解DataBinding是一个实现数据和UI绑定的框架，只是一个实现MVVM模式的工具。ViewModel和View可以通过DataBinding来实现单向绑定和双向绑定，这套UI和数据之间的动态监听和动态更新的框架Google已经帮我们做好了。在MVVM模式中ViewModel和View是用绑定关系来实现的，所以有了DataBinding使我们构建AndroidMVVM应用程序成为可能。之前看了很多关于DataBinding的博客和相关的一些Demo，大多数就是往xml布局文件传入一些数据，然后把这些数据绑定到控件上(如TextViewbinding:text=逗@{user.name})，接着在这些控件上（如Buttonbinding:setOnClickListener=地@{user.listener}地)设置一些事件到控件上，基本讲述都是DataBinding的基本用法。但是并没有人告诉你把一个onClickListener写到一个类并把这个listener绑定到xml里面上是不是不太好，也没有人告诉你这个和xml布局绑定的ViewModel类应该放哪些数据，应该做什么事看应该如何设计看更是很少有博文来告诉你在Android中如何通过DataBinding去构建MVVM的应用框架。这也就是是本篇文章的重点。接下来，我们先来看看什么是MVVM，然后在一步一步来设计整个应用程序框架。源码地址