是让人提神醒脑的 MVP、MVVM 关系精讲！

前言

很高兴见到你！

我是《Jetpack MVVM 精讲》的独立原创做者 KunMinX，GitHub star 8.7k，专一于深度思考和 Jetpack MVVM 的分享。

关于 MVP 和 MVVM 本质和区别的文章，原本我是不想写的，由于通过长达一年的耳濡目染 和对方法论的试炼，相信 但凡沉下心阅读过《重学安卓》体系化文章的读者，多已练就 透过表象迅速抓住本质 的稀缺能力。

专栏天天都有新的读者加入，然而没想到的是，1 年了，仍然时不时的会被咨询、或是在各个社区看到人们众说纷纭地在谈论 MVP 和 MVVM 谁“好”谁“坏”。

并非每个提问都值得被回答

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

换言之，并非每个提问都值得被回答。一次提问所包含的信息量，其实远远超出内容自己。

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

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

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

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

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

本质和区别，我只说一遍

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

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

因此，本文只写给那些 真的想搞清楚事实 的有缘人，只为有缘人铺路。

而且关于 MVP 和 MVVM 各自的本质及区别，我就只说这么一遍，因此请认真阅读。

文章目录一览

• 前言
• 并非每个提问都值得被回答
• 本质和区别，我只说一遍
• 先说结论
• 因此两者的区别是什么？
• Jetpack MVVM 和 MVVM 模式的关系
• 我为何能瞬间感知沟通质量的 “好” 与 “坏” ？
• 综上

先说结论

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

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

MVVM 本质：是狭义上的架构模式，专用于页面开发。

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

因此两者的区别是什么？

区别就在于：

一个是广义上的架构：

你能够经过同一套逻辑去驱动不一样品牌设备的实体用户接口（好比不一样品牌的耳机线控），或虚拟用户接口（好比 Android 视图，但存在一致性问题而不推荐）；

一个是狭义上的架构：

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

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

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

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

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

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

任何我的或组织在转载全文，或引用本文中上述提到的 描述、举例、图例或本质归纳 时，须注明原做者和出处。未经受权不得用于洗稿、广告包装等商业用途。