写点什么

是让人 - 提神醒脑 - 的 -MVP、MVVM- 关系精讲!,2021 最新 Android 开发面试解答

用户头像
Android架构
关注
发布于: 20 小时前

Jetpack MVVM 和 MVVM 模式的关系

Jetpack MVVM 是 MVVM 模式在 Android 开发中的一个具体落实,也即它不仅仅包含了 MVVM 模式用于解决 “视图调用的一致性问题” 这一本质,还兼顾了 Android 页面开发中其他不可预期的错误。


正如我在[《 Jetpack MVVM 精讲》](


)中介绍到的:


Lifecycle 的存在,主要是为了解决 生命周期管理 的一致性问题


LiveData 的存在,主要是为了帮助 新手老手 都能不假思索地 遵循 通过唯一可信源分发状态 的标准化开发理念,从而在快速开发过程中 规避一系列 难以追溯、难以排查、不可预期 的问题。


ViewModel 的存在,主要是为了解决 状态管理 和 页面通信 的问题


DataBinding 的存在,主要是为了解决 视图调用 的一致性问题


它们的存在 大都是为了 在软件工程的背景下 解决一致性的问题、将容易出错的操作在后台封装好,方便使用者快速、稳定、不产生预期外错误地编码


所以,Jetpack MVVM 的高频核心架构组件,和 iOS、WPF 的实现一定是有区别的,只不过抓住本质,我们就能举一反三,以不变应万变。


通过[《事关软件工程安全 的 数据驱动 UI 框架 扫盲干货》](


)一文的介绍我们可知,DataBinding 的唯一挑战者是 基于函数式编程的数据驱动 UI 框架,也即发源自前端 Elm 框架的 React、Flutter、Jetpack Compose、SwiftUI 之流。


所以 React、Flutter 这种,算不算 MVVM 呢?其实也算。DataBinding 被换下了,但视图调用一致性问题有函数式编程来解决。


所以 ...

我为什么能瞬间感知沟通质量的 “好” 与 “坏” ?

事实上,在 “先说结论” 一节介绍完本质后,按照惯例,我是会以 “如果这样说还没有理解的话” 来引出下文,开始交代 “Before” 和 “After” 的,


因为每天都有新的读者加入,为方便新读者能够 结合自己的兴趣 随机阅读,专栏几乎每一篇文章 都是以独立专辑的完整度来发行


这也是为什么,我的每一篇文章,都当做自己是第一次和读者见面、不遗余力地贯彻 全网独家的深度思考写作风格,让每一位新读者都有机会和我注入到文章的灵魂发生交流。


然而这一次,我不得不小小地任性一把,因为如果上述这样说了一通,还是不理解的话,答案早就写在以下几篇里:


[《是 持续增量更新 的 背景缘由甜点》](


) 的 “饭后甜点不能当主食吃” 一节 (推荐)


[《基本功:是随时随地可受用的 深度思考秘诀》](


) 的 “所以如何正确地思考” 一节;


[《这是一份 简洁有力的 认知地图》](


) 的 “认知地图” 一节;


还有近期在掘金开源的[《独家解析 | Android 深度思考写作技巧》](


) 的 “公式” 一节 ——


这几处都有 就正确的思维方式 提供方法论依据 以及手把手示范


一旦熟悉了这套方法论,那些没完没了的争论,你会不会参与?我想大概率不会,因为你一眼就看出 这些言论中不包含基于事实的思考,不过是 凭主观感觉、个人喜好 的自说自话。


参与到这种扯淡中 是对自己的不尊重,所以你不会参与。

综上

MVP 的本质是对 MVC 的依赖倒置,借此来解决 逻辑复用难 以及 实现替换难 的问题,


因为在 MVP 下,UI 逻辑和业务逻辑全在 Presenter 中写,UI 和 Model 的实现,可以随意替换,


也即如上文介绍的,通过同一套 Presenter 中的逻辑,可以驱动不同品牌不同型号的耳机的线控。(注意 UI 的全称是 “用户接口”,台湾的术语更准确,叫 “用户介面”。UI 不是狭义上的页面,UI 就是 UI)


MVVM 的本质是对 View 数据的映射,借此来在软工背景下解决 视图调用的一致性问题。


MVP 和 MVVM 二者的区别在于,前者是广义的架构模式,普遍适用后者是狭义上的架构模式,专用于页面开发,可以解决例如 视图调用的一致性问题,来规避不可预期的错误。


也即 MVP 和 MVVM 本质上毫无关系,没有谁演化自谁


Jetpack MVVM 是 MVVM 模式在 Android 下的一个落地,也即除了解决 视图调用的一致性问题,还因地制宜地解决了其他一致性问题,从而规避各种不可预期的错误,让软件开发的工作得以完成得又快又好。


这样说,你理解了吗?

版权声明

本文以 [CC 署名-非商业性使用-禁止演绎 4.0 国际协议](


) 发行。


Copyright ? 2019-present KunMinX


[图片上传中...(image-3bb66c-1594170447308-0)]


<figcaption></figcaption>


文中提到的 关于 “MVP 和 MVVV 各自的本质及区别” 的具体描述、”用户介面与耳机线控“ 的举例、架构设计图例、”DataBinding 与函数式编程数据驱动框架的关系“ 的具体描述、”Jetpack MVVM 和 MVVM 关系“ 的描述、”Lifecycle、LiveData、ViewModel、DataBinding 等架构组件的存在意义“ 等多处 对特定现象及其本质的概括,均属于本人独立原创的成果,本人对此享有最终解释权。


任何个人或组织在转载全文,或引用本文中上述提到的 描述、举例、图例或本质概括 时,须注明原作者和出处。未经授权不得用于洗稿、广告包装等商业用途。


作者:KunMinX 链接:https://juejin.im/post/5f03ef91f265da22df3ccc5a来源:掘金著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


<figcaption></figcaption>

并不是每一个提问都值得被回答

爱因斯坦说,“提出正确的问题,问题就已解决了一半”。


换言之,并不是每一个提问都值得被回答。一次提问所包含的信息量,其实远远超出内容本身


透过提问者的提问,几乎可以瞬间感知到,提问者对事实状况的掌握程度,并由此来决定到底值不值得继续交流。


与“高”质量提问者的交流 让人感到如沐春风 —— 几句话就能自己先把背景交代清楚,然后就某个细节提出自己的困惑 —— 这让我不免想要与之多聊几句,把我知道的毫无保留地分享出去。


反之,“低”质量提问 让人感到 不舒服,甚至不对劲 —— 明明不遗余力地在多处 划重点 反复交代,明明白纸黑字写得清清楚楚,甚至段落、链接给他指出来,却视而不见,就好像从未发生过。


注:我从不在技术交流中使用 “高”、“低”、“好”、“坏”、“轻”、“重” 之类的主观描述,此处只是以多数人方便理解的方式来介绍。文中使用到的主观描述一律加上双引号。


更有甚者,为了满足抬杠的快感,不惜浪费彼此的时间 ...

本质和区别,我只说一遍

事实上,我并不会去判断来者是否是来抬杠,而只须透过对方所说的话,即可瞬间判断对方说的是事实,还是自顾自地扯淡 —— 你没法和一个前来扯淡的人交流,你会发现 这种对话往往 存在巨大的代沟,并且抬杠者无意谋求和缝合对事实的理解,他本来就是为了 “来的快” 的精神胜利而来。


事实即 "就事论事",事实必有特定背景和目的来约束。一切脱离事实特征的意见和观点都是瞎扯淡,没有讨论的前提、不值得参与 —— ?KunMinX


所以,本文只写给那些 真的想搞清楚事实 的有缘人,只为有缘人铺路。


并且关于 MVP 和 MVVM 各自的本质及区别,我就只说这么一遍,所以请认真阅读。

文章目录一览

  • 前言

  • 并不是每一个提问都值得被回答

  • 本质和区别,我只说一遍

  • 先说结论

  • 所以二者的区别是什么?

  • Jetpack MVVM 和 MVVM 模式的关系

  • 我为什么能瞬间感知沟通质量的 “好” 与 “坏” ?

  • 综上

先说结论

MVP 本质:是广义上的架构模式,适用于面向实体或虚拟用户接口的开发。


它主要是在 MVC 的背景下,通过 依赖倒置,来解决 逻辑复用 难、实现更替 难 的问题。


MVVM 本质:是狭义上的架构模式,专用于页面开发


它主要是在多人协作的软件工程的背景下,通过只操作 ViewModel 中映射的视图数据 来刷新视图状态,以此来解决 视图调用的一致性问题 从而规避不可预期的错误。

所以二者的区别是什么?

区别就在于:


一个是广义上的架构


你可以通过同一套逻辑去驱动不同品牌设备的实体用户接口(比如不同品牌的耳机线控),或虚拟用户接口(比如 Android 视图,但存在一致性问题而不推荐);


[图片上传中...(image-307d3b-1594170394865-3)]


<figcaption></figcaption>


一个是狭义上的架构


专用于可视化页面的开发,通过解决一致性问题 来规避不可预期的错误。


[图片上传中...(image-3ebbf8-1594170394864-2)]


<figcaption></figcaption>


所以轻易地你就可发现,二者分别适用于 在各自的专场下 解决不同的问题,根本没有可比性,更没有所谓的 谁“好”谁“坏” 之分。


而且除了没有可比性,二者之间其实也没任何关系,MVP 的特质是 依赖倒置,MVVM 的特质是 数据驱动,二者没有说谁演化自谁的关系。回到刚刚所说的:“根本就是 特定场景下解决特定问题 的两种截然不同的架构模式”。


没有所谓的 MVVM == MVP + DataBinding,正如没有所谓的 雷峰塔 == 雷锋 + 塔。

Jetpack MVVM 和 MVVM 模式的关系

Jetpack MVVM 是 MVVM 模式在 Android 开发中的一个具体落实,也即它不仅仅包含了 MVVM 模式用于解决 “视图调用的一致性问题” 这一本质,还兼顾了 Android 页面开发中其他不可预期的错误。


正如我在[《 Jetpack MVVM 精讲》](


)中介绍到的:


Lifecycle 的存在,主要是为了解决 生命周期管理 的一致性问题


LiveData 的存在,主要是为了帮助 新手老手 都能不假思索地 遵循 通过唯一可信源分发状态 的标准化开发理念,从而在快速开发过程中 规避一系列 难以追溯、难以排查、不可预期 的问题。


ViewModel 的存在,主要是为了解决 状态管理 和 页面通信 的问题


DataBinding 的存在,主要是为了解决 视图调用 的一致性问题


它们的存在 大都是为了 在软件工程的背景下 解决一致性的问题、将容易出错的操作


《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


在后台封装好,方便使用者快速、稳定、不产生预期外错误地编码


[图片上传中...(image-2108cb-1594170394863-1)]


<figcaption></figcaption>


所以,Jetpack MVVM 的高频核心架构组件,和 iOS、WPF 的实现一定是有区别的,只不过抓住本质,我们就能举一反三,以不变应万变。


通过[《事关软件工程安全 的 数据驱动 UI 框架 扫盲干货》](


)一文的介绍我们可知,DataBinding 的唯一挑战者是 基于函数式编程的数据驱动 UI 框架,也即发源自前端 Elm 框架的 React、Flutter、Jetpack Compose、SwiftUI 之流。


所以 React、Flutter 这种,算不算 MVVM 呢?其实也算。DataBinding 被换下了,但视图调用一致性问题有函数式编程来解决。


所以 ...

我为什么能瞬间感知沟通质量的 “好” 与 “坏” ?

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
是让人-提神醒脑-的-MVP、MVVM-关系精讲!,2021最新Android开发面试解答