提神醒脑 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 国际协议发行。

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

当您借鉴或引用本文的引言、思路、结论进行二次创作，或全文转载时，须注明链接出处，否则我们保留追责的权利。