從只會實現功能的“碼農”到軟體工程師、設計師的過渡。

  MVP/MVVM架構的優點和缺點？它的使用場景是什麼？
  MVC是一種框架模式而非設計模式，GOF把MVC看作是3種設計模式：觀察者模式、策略模式與組合模式的合體，而核心是觀察者模式。簡而言之，框架是大智慧，用來對軟體設計進行分工；設計模式是小技巧，對具體問題提出解決方案，以提高程式碼複用率，降低耦合度。

-- 我對移動端架構的思考- https://mp.weixin.qq.com/s?__biz=MzIwMTAzMTMxMg==&mid=2649492922&idx=1&sn=429b586ca376f3b532126b56185efb28&chksm=8eec8645b99b0f53f4ab12338703124f34909042822d8e2c2aea219df43180fef764205bde2b&scene=38#wechat_redirect
移動端架構的差異化體現在通訊機制上。通訊機制主要分為3種：

-- MVP的問題在於，由於我們使用了介面的方式去連線view層和presenter層，這樣就導致了一個問題，如果你有一個邏輯很複雜的頁面，你的介面會有很多，十幾二十個都不足為奇。想象一個app中有很多個這樣複雜的頁面，維護介面的成本就會非常的大。這個問題的解決方案就是你得根據自己的業務邏輯去斟酌著寫介面。你可以定義一些基類介面，把一些公共的邏輯，比如網路請求成功失敗，toast等等放在裡面，之後你再定義新的介面的時候可以繼承自那些基類，這樣會好不少。
  MVVM的問題呢，其實和MVC有一點像。data binding框架解決了資料繫結的問題，但是view層還是會過重。
  MVP+data binding，我們可以使用presenter去做和model層的通訊，並且使用data binding去輕鬆的bind data。

 最佳實踐都是人想出來的，用這些框架根本的原因也是為了儘量低的耦合性和儘量高的可複用性。
 activity在MVVM中應該是view層的，但是裡面卻和MVC一樣寫了對model的處理。有人會說你可以把對model的處理放到viewmodel層中，這樣不是更符合MVVM的設計理念嗎？這樣確實可以，但是progressDialog的show和dismiss呢？你怎麼在viewmodel層中控制？這是view層的東西啊，而且在xml中也沒有，我相信會有解決的方案，但是我們有沒有一種更加便捷的方式呢？
  MVP和MVVM在分解app使其模組化方面都比MVC更好，但它們也帶來了複雜性。對於一個只有一兩個介面的app，MVC可以很好地工作。MVVM的資料繫結很吸引力，它是更靈活的程式設計模式並且可以寫更少的程式碼。

  架構設計的目的：通過設計使程式模組化，做到模組內部的高聚合和模組之間的低耦合。這樣做的好處是使得程式在開發的過程中，開發人員只需要專注於一點，提高程式開發的效率，並且更容易進行後續的測試以及定位問題。但設計不能違背目的，對於不同量級的工程，具體架構的實現方式必然是不同的，切忌犯為了設計而設計，為了架構而架構的毛病。

MVC與MVP兩種模式的主要區別：
 1.（最主要區別）View與Model並不直接互動，而是通過與Presenter互動來與Model間接互動。而在MVC中View可以與Model直接互動
 2.通常View與Presenter是一對一的，但複雜的View可能繫結多個Presenter來處理邏輯。而Controller是基於行為的，並且可以被多個View共享，Controller可以負責決定顯示哪個View
 3.Presenter與View的互動是通過介面來進行的，更有利於新增單元測試。

MVP的優點如下：
 1、模型與檢視完全分離，我們可以修改檢視而不影響模型；
 2、可以更高效地使用模型，因為所有的互動都發生在一個地方——Presenter內部；
 3、我們可以將一個Presenter用於多個檢視，而不需要改變Presenter的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁；
 4、如果我們把邏輯放在Presenter中，那麼我們就可以脫離使用者介面來測試這些邏輯（單元測試）。

> MVC

  MVC全稱是Model - View - Controller，是模型(model)－檢視(view)－控制器(controller)的縮寫。MVC是一種框架模式而非設計模式，GOF把MVC看作是3種設計模式：觀察者模式、策略模式與組合模式的合體，而核心是觀察者模式。簡而言之，框架是大智慧，用來對軟體設計進行分工；設計模式是小技巧，對具體問題提出解決方案，以提高程式碼複用率，降低耦合度。
a.MVC的優點：
（1）首先就是理解比較容易，技術含量不高，這對開發和維護來說成本較低也易於維護與修改。
（2）耦合性不高，表現層與業務層分離各司其職，對開發來說很有利。所謂耦合性就是模組程式碼之間的關聯程度。利用MVC框架使得View（檢視）層和Model（模型）層可以很好的分離，這樣就達到了解耦的目的，所以耦合性低，減少模組程式碼之間的相互影響。

  (3)可擴充套件性好。由於耦合性低，新增需求，擴充套件程式碼就可以減少修改之前的程式碼，降低bug的出現率。
  (4)模組職責劃分明確。主要劃分層M,V,C三個模組，利於程式碼的維護。
b.MVC的缺點：
（1）完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。同時由於模型和檢視要嚴格的分離，這樣也給除錯應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。
（2）對於小專案，MVC反而會帶來更大的工作量以及複雜性。

-- MVC在Android中的應用
  Android中對MVC的應用很經典，在Android中檢視View層一般採用XML檔案進行介面的描述。
而對於模型Model部分則大多對應於本地的資料檔案或網路獲取的資料體，很多情況下我們對這些資料的處理也會在這一層中進行。最後的控制器Controller則當之無愧的是右Activity承擔。
  雖說上面的介紹中我們感受到Android在MVC方面的結構，但是，這個框架並非我們自己完成的，而是由framework給我們搭建好的並提供給我們，在平時的開發中，特別是用Android開發，我們並不常用到MVC模式去脫離Android UI系統構建自己的框架結構。

使用 MVC，把業務邏輯抽離到 Controller 中，讓 View 層專注於顯示 UI。
  Android中對MVC的應用很經典，在Android中檢視View層一般採用XML檔案進行介面的描述。如下例子：
<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="50dp"
    android:id="@+id/list_item_text"
    android:textSize="16sp"
    android:gravity="left|center_vertical"
    android:padding="10dp" />
  而對於模型Model部分則大多對應於本地的資料檔案或網路獲取的資料體，很多情況下我們對這些資料的處理也會在這一層中進行。最後的控制器Controller則當之無愧的是由Activity承擔。

-- MVC存在的問題:
  View強依賴於Model是MVC的主要問題。由此導致很多控制元件都是根據業務定製，從Android的角度來看，原本可以由一個通用的layout就能實現的控制元件，由於要繫結實體模型，現在必須要自定義控制元件，這導致出現大量不必要的重複程式碼。因此有必要將View和Model進行解耦，而MVP的主要思想就是解耦View和Model。由此引入MVP就顯得很自然。

> MVP

-- MVP 與Activity、Fragment的生命週期
  由於Presenter 經常性的持有Activity 的強引用，如果在一些請求結束之前Activity 被銷燬了，那麼Presenter 一直持有Activity 物件，使得Activity 物件無法回收，此時就會發生記憶體洩露。那麼解決方法就是採用弱引用和Activity、Fragment的生命週期來解決這個問題。

與mvp相關的開源專案：https://github.com/yaozs/YzsBaseActivity  https://github.com/yaozs/YzsLib
框架模式MVC與MVP在Android中的應用: http://blog.csdn.net/gjnm820/article/details/51733361
Google推出的基於MVP架構的demo,基於此架構我在GitHub上開源了一個專案MinimalistWeather
Android MVP框架MVPro的使用和原始碼分析- http://blog.csdn.net/qibin0506/article/details/49992897
淺談Andorid開發中的MVP模式- http://blog.csdn.net/loongggdroid/article/details/50592777

Android官方MVP架構解讀：http://blog.csdn.net/ljd2038/article/details/51477475
MVP sample: https://github.com/googlesamples/android-architecture

  MVP模式是MVC模式的一個演化版本，MVP全稱Model-View-Presenter。目前MVP在Android應用開發中越來越重要了。
在Android中，業務邏輯和資料存取是緊緊耦合的，很多缺乏經驗的開發者很可能會將各種各樣的業務邏輯塞進某個Activity、Fragment或者自定義View中，這樣會使得這些元件的單個型別臃腫不堪。如果不將具體的業務邏輯抽離出來，當UI變化時，你就需要去原來的View中抽離具體業務邏輯，這必然會很麻煩並且易出錯。
 -- 使用MVP的好處
（1）MVP模式會解除View與Model的耦合，有效的降低View的複雜性。同時又帶來了良好的可擴充套件性、可測試性，保證系統的整潔性和靈活性。
（2）MVP模式可以分離顯示層與邏輯層，它們之間通過介面進行通訊，降低耦合。理想化的MVP模式可以實現同一份邏輯程式碼搭配不同的顯示介面，因為它們之間並不依賴與具體，而是依賴於抽象。這使得Presenter可以運用於任何實現了View邏輯介面的UI，使之具有更廣泛的適用性，保證了靈活度。
 -- MVP模式的三個角色
（1）Presenter – 互動中間人：Presenter主要作為溝通View與Model的橋樑，它從Model層檢索資料後，返回給View層，使得View與Model之間沒有耦合，也將業務邏輯從View角色上抽離出來。
（2）View – 使用者介面：View通常是指Activity、Fragment或者某個View控制元件，它含有一個Presenter成員變數。通常View需要實現一個邏輯介面，將View上的操作轉交給Presenter進行實現，最後，Presenter 呼叫View邏輯介面將結果返回給View元素。
（3）Model – 資料的存取：Model 角色主要是提供資料的存取功能。Presenter 需要通過Model層儲存、獲取資料，Model就像一個數據倉庫。更直白的說，Model是封裝了資料庫DAO或者網路獲取資料的角色，或者兩種資料方式獲取的集合。

 -- MVP存在的問題:
  儘管已經有了大量的應用，但不可否認該模式的還是存在一些問題，這些問題在攜程的使用過程中也得到了體現。比如，上下文丟失問題，生命週期問題，記憶體洩露問題以及大量的自定義介面，回撥鏈變長等問題。可以歸納為：
  1.業務複雜時，可能使得Activity變成更加複雜，比如要實現N個IView，然後寫更多個模版方法。
  2.業務複雜時，各個角色之間通訊會變得很冗長和複雜，回撥鏈過長。
  3.Presenter處理業務，讓業務變得很分散，不能全域性掌握業務，很難去回答某個業務究竟是在哪裡處理的。
  4.用Presenter替代Controller是一個危險的做法，可能出現記憶體洩漏，生命週期不同步，上下文丟失等問題。

> MVVM

   MVVM與MVP非常相似，唯一區別是View和Model進行雙向繫結，兩者之間有一方發生變化則會反應到另一方上。MVVM模式有點像ListView與Adapter、資料集的關係，當資料集發生變化時，呼叫Adapter的notifyDataSetChanged之後View就直接更新，同時它們之間又沒有耦合，使得ListView變得更加靈活。

> MVC與MVP的區別：

MVP中View不能直接訪問Model，需要通過Presenter發出請求，View與Model不能直接通訊。

> MVP與MVVM 的區別

    MVP與MVVM都是Android中比較好的應用架構模式，它們的優點都是能夠降低耦合，提升應 用模組的可測試性，並且能夠在一定程度上避免過於複雜的Fragment、Activity型別，使得整個軟體架構變得更為簡單、清晰。它們缺點主要是職責分得比較細，這樣必然會產生很多型別。例如一個Activity，需要有Model、View、Presenter三個元素，這三個元素又要分介面、實現類，頁面- 多各種Model、View、Presenter型別就繁雜起來。當然，通過合理的分包也能夠在一定程度上緩解這個問題帶來的負面影響。因 此，只要你想讓你的應用架構更靈活、可擴充套件、易測試，MVP、MVVM都是很好的選擇。

Android App的設計架構：MVC,MVP,MVVM與架構經驗談- https://www.cnblogs.com/wytiger/p/5305087.html
android中的MVC,MVP和MVVM模式簡單總結- https://blog.csdn.net/kaikevin01/article/details/78797700
 1.MVC
View：對應於xml佈局檔案
Model：實體模型
Controllor：對應於Activity業務邏輯，資料處理和UI處理
xml的view功能太過於弱化，導致actvity裡面即處理業務邏輯，又處理view。這樣activity的類的程式碼比較長。

 2.MVP
View:對應於Activity和xml，負責View的繪製以及與使用者互動
Model:依然是實體模型
Presenter: 負責完成View於Model間的互動和業務邏輯
用得比較多，把檢視操作和業務邏輯分開來。複雜的業務同時會導致presenter層太大，程式碼臃腫的問題。通過UI事件的觸發對資料進行處理。activity需要編寫大量的事件。通過事件呼叫presenter的業務處理方法。UI改變後牽扯的邏輯耦合度太高。View和Presenter只是互相持有引用並互相做回撥,程式碼不美觀。

 3.MVVM
View:對應於Activity和xml，負責View的繪製以及與使用者互動
Model:實體模型
ViewModel:負責完成View於Model間的互動,負責業務邏輯
資料繫結(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)