Android面試集錦系列(12)——Android開發的套路MVP & MVVM
上個月參加了敏捷之旅成都站的活動，其中有一個朋友分享了“提升軟體研發領導力的招式和模式”，模式用通俗一點的說法就是“套路”，他介紹了模式（套路）在我們生活和工作中的積極作用，“模式並不是一項新發明，而是一個被記錄和證實的最佳實踐或者一個解決方案，而且在特定環境下，模式是可以複製的”，包括我們常聽到的設計模式其實也是這樣。
一個人善於使用模式，相當於把一些特定問題進行了抽象概括，大腦其實可以騰出更大的空間處理別的事情（具體的業務等）。所以，這一兩年我也比較喜歡嘗試使用一些流行的模式或者開源框架到自己的專案中，最終不一定會投入使用，但嘗試的過程還是很有益處的。
今天就來和大家談一談最近一兩年在Android開發中比較火的模式：MVP & MVVM。
面試題：談談MVP和MVVM模式，你有在自己的專案中使用過嗎？
好吧，其實問過很多面試者，結果說明MVP和MVVM模式並沒有到婦孺皆知的境地。不過也好，這麼一個簡單的問題我們就可以很容易區分出面試者是否對Android開發有熱情。
在解釋MVP時，我們往往喜歡拿它和大眾都比較熟悉的MVC進行比較。
MVC全名是Model--View--Controller，是模型(model)－檢視(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、資料、介面顯示分離的方法組織程式碼，在改進和個性化定製介面及使用者互動的同時，不需要重新編寫業務邏輯。其中Model層處理資料，業務邏輯等；View層處理介面的顯示結果；Controller層起到橋樑的作用，來控制View層和Model層通訊以此來達到分離檢視顯示和業務邏輯層。
我們往往把Android中介面部分的實現也理解為採用了MVC框架，常常把Activity理解為MVC模式中的Controller。
而MVP其實是MVC的一種演進版本，它更簡單，將MVC中的Controller改為了Presenter，View通過介面與Presenter進行互動，降低耦合，方便進行單元測試。
View：負責繪製UI元素、與使用者進行互動(Activity、View、Fragment都可以做為View層)；
Model：對資料的操作、對網路等的操作，和業務相關的邏輯處理；
Presenter：作為View與Model互動的中間紐帶，處理與使用者互動的邏輯。可以把Presenter理解為一箇中間層的角色，它接受Model層的資料，並且處理之後傳遞給View層，還需要處理View層的使用者互動等操作。
我們看看如下的MVC和MVP的對比圖更能直觀的理解這兩種模式的區別：
最明顯的區別就是，MVC中是允許Model和View進行互動的，而MVP中很明顯，Model與View之間的互動由Presenter完成。
那麼我們為什麼需要MVP或者其他模式呢？現實中，我們常遇到一些不使用架構的專案（程式設計師都很任性，功能需求到哪裡程式碼就寫到哪裡），需求中的一個頁面對應專案中的一個activity或一個fragment，所有的介面響應程式碼、業務邏輯程式碼、資料請求程式碼等等都集中在其中，一個類的程式碼非常臃腫難於理解和維護。
如何在自己的專案中使用MVP
官方給我們寫了一些MVP的樣例工程，用不同的概念和工具實現同一個Todo專案。
- todo-mvp/ - mvp基礎架構示例。
- todo-mvp-loaders/ - 基於mvp基礎架構專案，獲取資料部分使用了Loaders架構。
- todo-databinding/ - 基於mvp基礎架構專案，使用了資料繫結元件。
- todo-mvp-clean/ - 基於mvp基礎架構專案，使用了clean架構的概念。
- todo-mvp-dagger/ - 基於mvp基礎架構專案，使用了dagger2進行依賴注入。
- todo-mvp-contentproviders/ - 基於todo-mvp-loaders架構專案，使用了Content Providers
- todo-mvp-rxjava/ - 基於mvp基礎架構專案，全名用RxJava進行併發和資料層處理。
雖然在官方推出這套MVP開源用例之前，網路上也有很多優秀的開源專案教大家如何使用MVP模式，如果你之前沒看過，其實現在還有一個好處，直接按官方的來做就是了（官方一出馬，其他的類似專案就啞火了）。我看了一下官方的todo-mvp確實比之前自己實現的要簡單明瞭一些，而且測試用例也寫得比較完整可以直觀體驗一下MVP在這方面的好處。
MVP的好處與問題
當你瞭解清楚MVP模式後，它的好處也就很明顯了：
- UI層和邏輯層分離，UI層不在涉及業務邏輯程式碼，某層的改動不需要到處去修改程式碼；
- 測試很方便，你可以直接呼叫Presenter層寫測試用式（可以使用Junit框架）；
- 最後是可維護性和可擴充套件性，MVP的各個類職責都非常明確且單一，後期的擴充套件，維護都會更加容易。
當然，壞處也很明顯，首先程式碼類增加了，一個小功能你可能要為它專門寫Presenter和Model層的實現，以前這些你一口氣就加在View層了。同時需要對新進專案的人員進行一些MVP模式的培訓，以便他們不會寫出破壞已有模式的程式碼。
MVVM模式
MVVM模式（Model--View--ViewModel模式），和MVP模式相比，MVVM 模式用ViewModel替換了Presenter ，其他層基本上與 MVP 模式一致，ViewModel可以理解成是View的資料模型和Presenter的合體。
MVVM採用雙向繫結（data-binding）：View的變動，自動反映在ViewModel，反之亦然，這種模式實際上是框架替應用開發者做了一些工作（相當於ViewModel類是由庫幫我們生成的），開發者只需要較少的程式碼就能實現比較複雜的互動。這一步對於我還是比較有吸引力了，可以少寫很多模板程式碼。
官方在Google I/O 2015大會上推出來MVVM模式的支援函式庫Data Binding Library。在Android Studio 2.1 Preview 3之後，開始支援雙向資料繫結，即在View層修改輸入也會觸發Model層的改變。
當然，做過WinPhone開發的人一定想起來了微軟在很多年前就在使用MVVM模式了。
小結
再次說明，你的專案並不一定非要用MVP/MVVM或者別的什麼模式，模式都有它們自身應用的場景，有好處也就會有壞處。但瞭解是必需的，不然你很難擴充套件自己的技能範圍，高階的開發應該學會判斷某個專案是否合適一些現成的模式，合理的使用模式會讓你的應用框架更加清晰並且易於維護和擴充套件。
最後
在這裡我總結出了網際網路公司Android程式設計師面試簡歷模板，面試涉及到的絕大部分面試題及答案做成了文件和架構視訊資料免費分享給大家【 包括高階UI、效能優化、架構師課程、NDK、Kotlin、混合式開發（ReactNative+Weex）、Flutter等架構技術資料 】，希望能幫助到您面試前的複習且找到一個好的工作，也節省大家在網上搜索資料的時間來學習。
資料獲取方式：加入Android架構交流QQ群聊：513088520 ，進群即領取資料！！！
點選連結加入群聊【Android移動架構總群】： 加入群聊
資料大全