前言
我使用 MVVM 設計模式也算是先驅者中的一員了（當初都還不明白 MVP 設計模式時，使用 MVC 的萬能 Activity 進行 Android App 開發(fā)），可是只是淺嘗而止，在撲咚健康App （遺憾，這個 App 看來并沒有上架，而是基于框架修改店員的平板客戶端）中嘗試了 databinding 測試版，一是對于測試版的不信任，二是之后項目的開發(fā)都排版決定了 MVP 設計模式。剛好這段時間返璞歸真，重新開始學習，所以決定仔細研究 MVVM 設計模式。
先來聊聊 MVC、MVP、MVVM
在傳統(tǒng)的框架中，提的最多的是MVC和MVP。其中MVC出現(xiàn)與上世紀70年代，在三十多年的工程實踐中，MVC充分證明了它的成功，同時在漫長的時間中演變出了許多變種，其中也包括MVP、MVC和MVP最大的差別在與控制層對于整個框架的控制力上。Android中經(jīng)常會出現(xiàn)數(shù)千行的Activity代碼，究其原因，我認為是Android中純粹作為View的各個XML視圖功能太弱，Activity基本上都是View和Controller的合體，既要負責視圖的顯示又要加入控制邏輯，承擔的功能過多，代碼量大也就不足為奇。所以我認為在Android上，MVP優(yōu)于MVC，是因為我們需要更強力的控制層最大程度上分擔Activity中邏輯的部分，具體的思想可以參考MagiLu的博客：Android App整體架構設計的思考(一)MVVM可以算是MVP的升級版，其中的VM是ViewModel的縮寫，ViewModel可以理解成是View的數(shù)據(jù)模型和Presenter的合體，ViewModel和View之間的交互通過Data Binding完成，而Data Binding可以實現(xiàn)雙向的交互，這就使得視圖和控制層之間的耦合程度進一步降低，關注點分離更為徹底，同時減輕了Activity的壓力，三者之間的差別如下如所示：
VM中View的數(shù)據(jù)模型每個頁面當然只有一套，但是Presenter的試用，建議根據(jù)邏輯拆開，不然 Presenter 就重蹈了萬能 Activity 的覆轍，出現(xiàn)了冗長的代碼串。
好好聊聊 MVVM
Android MVVM 設計模式的實現(xiàn)主要歸功于 Google 帶入的 Databinding，給 Google 點個贊。
MVC -> MVP -> MVVM 這幾個軟件設計模式是一步步演化發(fā)展的，MVVM 是從 MVP 的進一步發(fā)展與規(guī)范，MVP 隔離了 M 與 V 的直接聯(lián)系后，靠 Presenter 來中轉，所以使用 MVP 時 P 是直接調用 View 的接口來實現(xiàn)對視圖的操作的，這個 View 接口的東西一般來說是 showData、showLoading...M 與 V是隔離了，方便測試了，但代碼還不夠優(yōu)雅簡潔啊，所以 MVVM 就彌補了這些缺陷。在 MVVM 中就出現(xiàn)的 Data Binding 這個概念，意思就是 View 接口的 showData 這些實現(xiàn)方法可以不寫了，通過 Binding 來實現(xiàn)。。在 Android 中，我個人也是把 Activity、Fragment 當做 View 層的東西的，題主所說 ”一些邏輯操作與當前Context有關“，除了彈 Dialog（而且這也是 View），其它情況基本可以自己重寫 Application 來拿 ApplicationContext，那么題主所說的邏輯操作可以不在 Activity、Fragment 出現(xiàn)吧。VM 也是 M 與 V 的橋梁啊，怎么會有很多操作呢～一般場景下一個 View 就會有一個相應的 VM。最后分享一個網(wǎng)站，https://speakerdeck.com （Speakerdeck of GitHub Inc - 在線簡報、PDF分享展示平臺?。┮约跋旅娴膬蓚€與題目相關的PPT。Clean Android Architecture（這里有 Coursera App Architecture 的設計分析哦，很贊，Demo App 的 Github）。
How to use MVVM pattern in Android (Droidcon Krakow 2014Last：Architecting Android…The clean way（自行搜索譯文）
