RELATEED CONSULTING
相关咨询
选择下列产品马上在线沟通
服务时间:8:30-17:00
你可能遇到了下面的问题
关闭右侧工具栏

新闻中心

这里有您想知道的互联网营销解决方案
androidmvvm框架,android mvvm双向绑定

安卓studio 怎么搭建mvvm

如何分工

创新互联公司专注为客户提供全方位的互联网综合服务,包含不限于网站设计制作、成都网站制作、临安网络推广、微信小程序、临安网络营销、临安企业策划、临安品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;创新互联公司为所有大学生创业者提供临安建站搭建服务,24小时服务热线:18982081108,官方网址:www.cdcxhl.com

构建MVVM框架首先要具体了解各个模块的分工,接下来我们来讲解View,ViewModel,Model 的它们各自的职责所在。

View

View层做的就是和UI相关的工作,我们只在XML和Activity或Fragment写View层的代码,View层不做和业务相关的事,也就是我们的Activity 不写和业务逻辑相关代码,也不写需要根据业务逻辑来更新UI的代码,因为更新UI通过Binding实现,更新UI在ViewModel里面做(更新绑定的数据源即可),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,对于每个事件我们用一个ReplyCommandT去处理就行了,ReplyCommandT会把可能你需要的数据带给你,这使得我们处理事件的时候也只关心处理数据就行了,具体见MVVM Light Toolkit 使用指南的 Command 部分。再强调一遍ViewModel 不做和UI相关的事。

Model

Model 的职责很简单,基本就是实体模型(Bean)同时包括Retrofit 的Service ,ViewModel 可以根据Model 获取一个Bean的ObservableBean( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段,最后把这些字段绑定到View层上。

总得来说ViewModel 和View 之前仅仅只有绑定的关系,View层需要的属性和事件处理都是在xml里面绑定好了,ViewModel层不会去操作UI,只会操作数据,ViewModel只是根据业务要求处理数据,这些数据自动映射到View层控件的属性上。关于ViewModel类中包含哪些模块和字段,这个需要开发者自己去衡量,这边建议ViewModel 不要引入太多的成员变量,成员变量最好只有上面的提到的5种(context、model、…),能不进入其他类型的变量就尽量不要引进来,太多的成员变量对于整个代码结构破坏很大,后面维护的人要时刻关心成员变量什么时候被初始化,什么时候被清掉,什么时候被赋值或者改变,一个细节不小心可能就出现潜在的Bug。太多不清晰定义的成员变量又没有注释的代码是很难维护

Model 是通过Retrofit 去获取网络数据的,返回的数据是一个ObservableBean( RxJava ),Model 层其实做的就是这些。那么ViewModel 做的就是通过传参数到Model层获取到网络数据(数据库同理)然后把Model的部分数据映射到ViewModel的一些字段(ObservableField),并在ViewModel 保留这个Model的引用,我们来看下这一块的大致代码(代码涉及到简单RxJava,如看不懂可以查阅入门一下.

如何构建Android MVVM 应用框架

View:XML布局文件。

Model:实体模型(数据的获取、存储、数据状态变化)。

Controllor:对应于Activity,处理数据、业务和UI。

从上面这个结构来看,Android本身的设计还是符合MVC架构的,但是Android中纯粹作为View的XML视图功能太弱,我们大量处理View的逻辑只能写在Activity中,这样Activity就充当了View和Controller两个角色,直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧!所以,更贴切的说法是,这个MVC结构最终其实只是一个Model-View(Activity:ViewController)的结构。

如何构建Android MVVM应用程序

Databinding 是一种框架,MVVM是一种模式,两者的概念是不一样的。我的理解DataBinding是一个实现数据和UI绑定的框架,只是一个实现MVVM模式的工具。ViewModel和View可以通过DataBinding来实现单向绑定和双向绑定,这套UI和数据之间的动态监听和动态更新的框架Google已经帮我们做好了。在MVVM模式中ViewModel和View是用绑定关系来实现的,所以有了DataBinding 使我们构建Android MVVM 应用程序成为可能。

Android真的推荐用MVI模式?MVI和MVVM有什么区别?

android自己卷自己,自己造一个MVI架构模式吗?

MVI架构模式是国内android开发者最近一两年造出来的吗?

看了很多MVI的资料,发现都提到cycle.js框架。android的mvi架构就是启发于cycle.js框架。

我们再看看Cycle.js框架是什么时候开始的,又是什么时候开始使用MVI模式的。

Cycle.js框架 第一个预发版本 :

再结合官方文档来看,Cycle.js框架就是为了MVI架构模式而生的。

虽然不知道,Cycle.js框架是不是首个MVI模式框架。

但是从很多资料可以推测,MVI架构模式就是Cycle.js框架推广开来的。

而且早在2014年就已经在前端开发中用得飞起了。

想想2014年,咱们在干嘛?android在用什么架构模式。

正所谓,天下武功出少林啊。

我们android的很多技术,在前端早就用“烂了”。

我们知道MVP和MVVM的爹都是MVC。MVI的爹也是MVC。

MVC的Controller是命令是编程组件,不能直接实现响应式编程思想。

响应式编程范式(Reactive programming):

安卓官方的compose框架、微信小程序、Flutter、React、鸿蒙UI的开发框架,都是使用响应式开发框架。

这里就不拓展开来讲了,上面提到的任何一个开发框架,你只要会一个基本就能理解响应式编程范式。

如果一个都不会也没关系,现在不理解响应式编程也没关系,等你学会MVI就理解了,这种只有实际使用过才能深刻理解。

学不会也没关系,不要焦虑(尤其那些工作不久的小伙伴,学不会属于正常现象~)

MVI,咱第一遍学不会,就等2年,再学一遍~

2年后也没学会,那就再等2年~ 一定要有耐心~

如果还是学不会,那也没关系,因为MVI早晚也会过时~ 等过时了就不用学了~

哈哈哈~ 别笑,正经Android可不会开玩笑的。

就像rxjava,当年有多少人死活学不会,android开发现在谁还学Rxjava?哈哈哈~

用一张图来总结这次升级的核心思想:

新版架构指南在旧版的基础上,做了如下调整和建议:

1. 将LiveData组件改成了StateFlow

对协程的使用更友好。并且更能体现面向数据流开发的思想。

实际上,依然使用LiveData也没毛病。

2. ViewModel传递给View的数据限制为View的UIState

ViewModel从Model层获取数据后,转换为UIState数据,通过StateFlow流向View层。

UIState的数据面向界面组件而定义的,是能直接控制View组件如何显示的数据。

所以我们也可以称UIState为界面的状态或者View的状态。

如下:

3. 单数据流还是多数据流的选择

官方指南并没有强制我们使用单流。

同一个界面应该使用单个StateFlow还是多个StateFlow,需要我们自己判断。

我们应该根据UIStates数据们之间关联程度来决定多流还是单流。

单流优缺点都十分明显:

优点: 数据集中管控,会提高代码的可读性和修改的便利性。

缺点: 当数据非常多且复杂时,会影响效率。因为我们没有diff功能,View层不能只更新有变化的数据,只会根据UIState刷新当前界面。

我们再看下官方新版架构图:

当然不仅仅MVVM可以改造成响应式开发范式,MVP也是可以的。

不信你看 这篇blog :

1. 理解MVC架构模式的思想【MVC是其他架构模式之爹,他的思想是MVP、MVVM、MVI的基础,学会它是关键步骤~】。

3. 学习kotlin的StateFlow组件,的使用:Sequence-Flow-StateFlow。

4. 学习ViewModel组件的使用(虽然不用ViewModel也能实现MVI架构,但是ViewModel还是值得学习)。

5. 理解DRY(Don't Repeat Yourself)原则。

6. 理解MVVM(因为官方的MVI模式是基于MVVM的基础改造的~)。

7. 学习官方架构指南。

8. 实战。

在这里就分享一份由大佬亲自收录整理的 学习PDF+架构视频+面试文档+源码笔记 , 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料

这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理,帮助大家在未来取得一份不错的答卷。

当然,你也可以拿去查漏补缺,提升自身的竞争力。

真心希望可以帮助到大家,Android路漫漫,共勉!

如果你有需要的话,只需 私信我【进阶】即可获取

Android MVVM使用文档

Android MVVM模式离不开DataBinding,每个组件中都需要开启,包括宿主App

1、组件在自己的AndroidManifest.xml各自配置activity,application标签无需添加属性,也不需要指定activity的intent-filter。当合并打包时,gradle会将每个组件的AndroidManifest合并到宿主App中。

组件关联到宿主时AndroidManifest.xml示例:

当我们程序的程序需要跳转到组件module-main里面的MainActivity时,就在组件module-main的AndroidManifest.xml里面声明

2、组件独立运行时,就需要单独的一个AndroidManifest.xml作为调试用。可以在src/main文件夹下创建一个alone/AndroidManifest.xml。配置application标签属性,并指定启动的activity。这个跟宿主APP的AndroidManifest.xml配置结构是一样的


文章名称:androidmvvm框架,android mvvm双向绑定
URL标题:http://scyingshan.cn/article/dsohpsi.html