详解Android框架MVVM分析以及使用

android mvvm 分析以及使用

首先我们需要知道什么是mvvm，他的功能和优点，以及他的缺点。

mvvm是model-view-viewmodel的简写。它本质上就是mvc 的改进版。mvvm 就是将其中的view 的状态和行为抽象化，让我们将视图 ui 和业务逻辑分开。当然这些事 viewmodel 已经帮我们做了，它可以取出 model 的数据同时帮忙处理 view 中由于需要展示内容而涉及的业务逻辑。微软的wpf带来了新的技术体验，如silverlight、音频、视频、3d、动画……，这导致了软件ui层更加细节化、可定制化。同时，在技术层面，wpf也带来了 诸如binding、dependency property、routed events、command、datatemplate、controltemplate等新特性。mvvm（model-view-viewmodel）框架的由来便是mvp（model-view-presenter）模式与wpf结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有mvp框架并且把wpf的新特性糅合进去，以应对客户日益复杂的需求变化。

wpf的数据绑定与presentation model相结合是非常好的做法,使得开发人员可以将view和逻辑分离出来,但这种数据绑定技术非常简单实用，也是wpf所特有的，所以我们又称之为model-view-viewmodel(mvvm)。这种模式跟经典的mvp（model-view-presenter）模式很相似，除了你需要一个为view量身定制的model，这个model就是viewmodel。viewmodel包含所有由ui特定的接口和属性，并由一个 viewmodel 的视图的绑定属性，并可获得二者之间的松散耦合，所以需要在viewmodel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。
在视图（view）部分，通常也就是一个aspx页面。在以前设计模式中由于没有清晰的职责划分，ui 层经常成为逻辑层的全能代理，而后者实际上属于应用程序的其他层。mvp 里的m 其实和mvc里的m是一个，都是封装了核心数据、逻辑和功能的计算关系的模型，而v是视图（窗体），p就是封装了窗体中的所有操作、响应用户的输入输出、事件等，与mvc里的c差不多，区别是mvc是系统级架构的，而mvp是用在某个特定页面上的，也就是说mvp的灵活性要远远大于mvc，实现起来也极为简单。
我们再从iview这个interface层来解析，它可以帮助我们把各类ui与逻辑层解耦，同时可以从ui层进入自动化测试（unit/automatic test）并提供了入口，在以前可以由winform/web form/mfc等编写的ui是通过事件windows消息与iview层沟通的。wpf与iview层的沟通，最佳的手段是使用binding，当然，也可以使用事件；presenter层要实现iview，多态机制可以保证运行时ui层显示恰当的数据。比如binding，在程序中，你可能看到binding的source是某个interface类型的变量，实际上，这个interface变量引用着的对象才是真正的数据源。
mvc模式大家都已经非常熟悉了，在这里我就不赘述，这些模式也是依次进化而形成mvc—>mvp—>mvvm。有一句话说的好：当物体受到接力的时候，凡是有界面的地方就是最容易被撕下来的地方。因此，iview作为公共视图接口约束（契约）的一层意思；view则能传达解耦的一层意思。

设计模式

因为wpf技术出现，从而使mvc架构模式有所改进，mvvm 模式便是使用的是数据绑定基础架构。它们可以轻松构建ui的必要元素。
可以参考the composite application guidance for wpf(prism)
view绑定到viewmodel，然后执行一些命令在向它请求一个动作。而反过来，viewmodel跟model通讯，告诉它更新来响应ui。这样便使得为应用构建ui非常的容易。往一个应用程序上贴一个界面越容易，外观设计师就越容易使用blend来创建一个漂亮的界面。同时，当ui和功能越来越松耦合的时候，功能的可测试性就越来越强。
在mvp模式中，为了让ui层能够从逻辑层上分离下来，设计师们在ui层与逻辑层之间加了一层interface。无论是ui开发人员还是数据开发人员，都要尊重这个契约、按照它进行设计和开发。这样，理想状态下无论是web ui还是window ui就都可以使用同一套数据逻辑了。借鉴mvp的iview层，养成习惯。view model听起来比presenter要贴切得多；会把一些跟事件、命令相关的东西放在mvc的'c',或者是mvvm的'vm'。

mvvm优点

mvvm模式和mvc模式一样，主要目的是分离视图（view）和模型（model），有几大优点

1. 低耦合。视图（view）可以独立于model变化和修改，一个viewmodel可以绑定到不同的"view"上，当view变化的时候model可以不变，当model变化的时候view也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个viewmodel里面，让很多view重用这段视图逻辑。
3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（viewmodel），设计人员可以专注于页面设计，使用expression blend可以很容易设计界面并生成xaml代码。
4. 可测试。界面素来是比较难于测试的，测试可以针对viewmodel来写。

mvvm控件

使用mvvm来开发用户控件。由于用户控件在大部分情况下不涉及到数据的持久化，所以如果将m纯粹理解为domainmodel的话，使用mvvm模式来进行自定义控件开发实际上可以省略掉m，变成了vvm

mvvm的核心是databidning 这是一个用于数据双向绑定的，他的强大之处，出了双向绑定之外，还可以代替butterknife。众所周知butterknife需要对每一个控件进行单独的绑定，这样子不但非常的费时间，而且会导致代码看起来极其的复杂。下面上图展示一下实际的差距。

这是butterknife这个样子只是进行了，绑定但是在用的时候还是不够方便因为你去要根据你的id去写出，对应的id方可进行操作。

这个databinding的是绑定声明，使用起来是这样子的

databinding后面直接点就可以，选择绑定页面的中的控件。
而且他的强大之处就是，databinding绑定之后就相当于一个viewgroup。这个在适配器中或者自定义页面的情况下极大地减少了，代码量。而且更不易出错。非常的稳定。
那么可能会有人问，既然使用了kotlin，那么我为什么还有使用databinding呢，没错总是有些杠精要和你杠一下，kotlin中的自带的id调用，是不错的。除非的你每个id开通都不重复否则。

那你就等根据后面的所属的activity慢慢选吧，而且kotlin绑定的控件，无法传递内存地址，你想把这个控件传到适配器里，那是不可能的。

接下来我们就说一下databinding的数据绑定，databinding自带的数据双向绑定，首先在使用之间，需要在gradle引入

这就就是打开databinding，那么如果使用数据绑定

首先使用databinding时 布局必须以开头，结尾。然后就可以在代码中绑定以开头结尾的文件了。

然后在布局中声明的id，

就可以直接调用

现在只是绑定了布局，还并没有绑定数据，数据绑定可以使bean也可以直接是数据。下面是数据的绑定，可以直接在

也可以在代码中声明一个数据源，例如：

这个要在标签中声明。type就是他的类型。然后在代码中绑定这个数据

然后就可以直接在布局中设置数据了

这个样子已经是实现了，datanbinding的双向绑定，但是还不是 所有，当数据刷新时，我们通常需要手动刷新或者在代码里重新赋值，但是databinding是不需要的，你只需要在bean中实现一个生命就可以，例如

在类的后面继承baseobservable（是每一个类，一个bean中可能有多个类），

然后在get方法上面声明@bindable，之后就可以了。当数据发生改变，绑定的数据就会自动改变，是不是很强大。现在只是介绍了databinding，接下来我们来看看mvvm。
mvvm分为model，view，modelview（简称vm），所以我们在使用是就可以像mvp一样分开文件，具有解耦效果，为了保证代码的安全性，我们分别使用modelipl，vmipl，就是让他们继承自接口，保证文件的安全性，下面开始实战操作。
首先是model

然后实现model的接口modelipl

然后是viewmodellistener（vm）

vm

最后就是讲view和vm绑定
就是activity或者fragment

需要说明一个fragment/adapter/viewgroup中需要一个layoutinflater这个就决定了activity的绑定方式和fragment的绑定方式不是相同的，下面说一个fragment中的绑定方式。（adapter和viewgroup的也是相同的方法）

itemmyorderlist1binding 这个就是你布局的名字后面加上一个binding。
最后送上套简单的activity和fragment的封装

以上就是详解android框架mvvm分析以及使用的详细内容，更多关于android框架mvvm使用的资料请关注其它相关文章！