前言
大家好，我是《Jetpack MVVM 精讲》独立原创作者 KunMinX，GitHub star 15k，专注 “深度思考原则” 和 “业务架构模式” 分享。
关于 MVP 和 MVVM 本质和区别文章，本不想单独写，因为但凡反复通读过《重学安卓》体系化文章读者，多已练就 透过表象迅速抓住本质 稀缺能力来自行完成推理。
不过让人意外的是，时不时会收到咨询、或在各个社区看到人们众说纷纭谈论 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 的存在，主要为解决 “视图实例 Null 安全” 一致性问题。
它们的存在，大都为在软件工程背景下 解决一致性问题、将容易出错操作在后台封装好，方便使用者快速、稳定、不产生预期外错误编码。
所以，Jetpack MVVM 高频核心架构组件，和 iOS、WPF 实现一定有所区别，只不过抓住本质，我们便能举一反三，以不变应万变。
通过《一通百通 “声明式 UI” 扫盲干货》一文我们可知，基于 “自动化生成中间代码来实现数据绑定” DataBinding，其唯一挑战者是 基于函数式编程思想 数据驱动 UI 框架，也即发源自前端 Elm 框架的 React、Flutter、Jetpack Compose、SwiftUI 之流。
所以像 Flutter 这种，算不算 MVVM？不算，但二者本质皆是去 解决视图实例 Null 安全一致性问题。
所以 ...
我为何能瞬间感知沟通质量 “好” 与 “坏” ？
事实上，在 “先说结论” 一节介绍完本质后，按照惯例，我是会以 “如这么说无体会” 引出下文，开始交代 “Before” 和 “After”，
因每天都有新读者加入，为方便新读者能 结合自身兴趣 随机阅读，专栏几乎每一篇文章 都是以独立专辑完整度发行。
这也是为何，我每篇文章，都当做自己是第一次和读者见面、不遗余力贯彻 全网独家深度思考写作风格，让每一位新读者都有机会和我注入到文章的灵魂发生交流。
然而这一次，我不得不小小任性一把，因为如上述说一通，还是无体会，答案早就写在以下几篇里：
《虽冷门但有用 背景缘由拾遗》 “饭后甜点不能当主食吃” 一节；
《基本功：是 “随时随地可受用” 深度思考原则》 “所以如何正确思考” 一节；
《这是一份 “简洁有力” 认知地图》 “认知地图” 一节；
这几处都有 就正确思维方式 提供方法论依据 及手把手示范。
一旦熟悉这套方法论，那些没完没了的争论，你会不会参与？我想大概率不会，因为你一眼就看出 这些言论中不包含基于事实的思考，不过是无原则无底线，以争夺话语权为目的 的自说自话。
参与到这种扯淡中 是对自己的不尊重，所以你不会参与。
综上
MVP 本质是对 MVC 依赖倒置，借此解决 逻辑复用难 及 实现替换难 问题，
因为在 MVP 下，UI 逻辑和业务逻辑全在 Presenter 中写，UI 和 Model 实现可随意替换，
也即如上文所述，通过同一套 Presenter 逻辑，可驱动不同品牌不同型号耳机线控。（注意 UI 全称是 “用户接口”，台湾术语更准确，叫 “用户介面”。UI 非狭义上页面，UI 就是 UI）
MVVM 本质是对 View 数据映射，借此来在软工背景下解决 视图实例 Null 安全一致性问题。
MVP 和 MVVM 二者区别在于，前者是广义架构模式，普遍适用；后者是狭义架构模式，专用于页面开发，可解决 视图实例 Null 安全一致性问题，规避不可预期错误。
也即 MVP 和 MVVM 本质上毫无关系，没有谁演化自谁。
Jetpack MVVM 是 MVVM 模式在 Android 一个落地，也即除解决 视图实例 Null 安全一致性问题，还因地制宜解决其他一致性问题，从而规避各种不可预期错误，让软件开发工作又快又好完成。
全文完
版权声明
本文以 CC 署名-非商业性使用-禁止演绎 4.0 国际协议 发行。
Copyright © 2019-present KunMinX
文中提到的 关于 “MVP 和 MVVV 各自的本质及区别” 的具体描述、“用户介面与耳机线控” 的举例、架构设计图例、“DataBinding 与函数式编程数据驱动框架的关系” 的具体描述、“Jetpack MVVM 和 MVVM 关系” 的描述、“Lifecycle、LiveData、ViewModel、DataBinding 等架构组件的存在意义”、“通过解决一致性问题来规避不可预期的错误” 等多处 对特定现象及其本质概括，均属本人独立原创成果，本人对此享有所有权和最终解释权。
当您借鉴或引用本文的引言、思路、结论进行二次创作，或全文转载时，须注明链接出处，否则我们保留追责权利。
