是讓人提神醒腦的 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 等架構組件的存在乎義「 等多處 對特定現象及其本質的歸納，均屬於本人獨立原創的成果，本人對此享有最終解釋權。

任何我的或組織在轉載全文，或引用本文中上述提到的 描述、舉例、圖例或本質歸納 時，須註明原做者和出處。未經受權不得用於洗稿、廣告包裝等商業用途。