編輯:關於Android編程
MVP模式是MVC模式的一個演化版本,MVP全稱Model-View-Presenter。目前MVP在Android應用開發中越來越重要了。
在Android中,業務邏輯和數據存取是緊緊耦合的,很多缺乏經驗的開發者很可能會將各種各樣的業務邏輯塞進某個Activity、Fragment或者自定義View中,這樣會使得這些組件的單個類型臃腫不堪。如果不將具體的業務邏輯抽離出來,當UI變化時,你就需要去原來的View中抽離具體業務邏輯,這必然會很麻煩並且易出錯。
(1)MVP模式會解除View與Model的耦合,有效的降低View的復雜性。同時又帶來了良好的可擴展性、可測試性,保證系統的整潔性和靈活性。
(2)MVP模式可以分離顯示層與邏輯層,它們之間通過接口進行通信,降低耦合。理想化的MVP模式可以實現同一份邏輯代碼搭配不同的顯示界面,因為它們之間並不依賴與具體,而是依賴於抽象。這使得Presenter可以運用於任何實現了View邏輯接口的UI,使之具有更廣泛的適用性,保證了靈活度。
(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或者網絡獲取數據的角色,或者兩種數據方式獲取的集合。
從上圖可以看出:MVC的耦合性還是較高的,View可以直接訪問Model,導致3者之間構成了回路。所以兩者的主要區別是,MVP中View不能直接訪問Model,需要通過Presenter發出請求,View與Model不能直接通信。
MVVM與MVP非常相似,唯一區別是View和Model進行雙向綁定,兩者之間有一方發生變化則會反應到另一方上。MVVM模式有點像ListView與Adapter、數據集的關系,當數據集發生變化時,調用Adapter的notifyDataSetChanged之後View就直接更新,同時它們之間又沒有耦合,使得ListView變得更加靈活。
可以參考:
1. androidmvp
2. archi
由於Presenter
經常性的持有Activity
的強引用,如果在一些請求結束之前Activity
被銷毀了,那麼Presenter
一直持有Activity
對象,使得Activity
對象無法回收,此時就會發生內存洩露。
那麼解決方法就是采用弱引用和Activity、Fragment的生命周期來解決這個問題。首先建立一個Presenter
抽象:
public abstract class BasePresenter {
protected Reference mViewRef; //View接口類型的弱引用
public void attachView(T view){
mViewRef = new WeakReference(view); //建立關聯
}
protected T getView(){
return mViewRef.get(); //獲取View
}
public boolean isViewAttached(){
return mViewRef != null && mViewRef.get() != null; //判斷是否與View建立關聯
}
public void detachView(){
if(mViewRef != null){
mViewRef.clear(); //解除關聯
mViewRef = null;
}
}
}
通常這個View
類型應該就是實現了某個特定接口的Activity
或者Fragment
等類型。
創建一個MVPBaseActivity
基類,通過這個基類聲明周期函數來控制它與Presenter
的關系。代碼如下:
public abstract class MVPBaseActivity> extends Activity {
protected T mPresenter; //Presenter對象
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mPresenter = createPresenter();
mPresenter.attachView((V)this);
}
@Override
protected void onDestroy() {
super.onDestroy();
mPresenter.detachView();
}
protected abstract T createPresenter();
}
MVPBaseActivity含有兩個泛型,一個是View的接口類型,一個是Presenter的具體類型。
PS:到這裡《Android源碼設計模式解析與實戰》讀書筆記系列到此就結束了,這本書算算看了也有近2個月了,收獲真是非常大,以後也會抽時間再看幾遍,溫故而知新嘛!在寫這個讀書筆記的過程中,很感謝大家的支持,評論中都是鼓勵的聲音真是給我了很多的信心。最讓我激動的是這本書的作者之一何紅輝也給了我鼓勵,在這裡也是再次感謝。
前一陣看到許多的博友都有寫年度總結,看了之後我也是很有感觸。那我也簡單總結一下:其實做Android開發到現在也有一年半了,雖然稱不上是什麼高手、大神。但是工作上的問題基本也可以獨立解決(畢竟有Google~,畢竟就我一人)同時我對我的工作和學習態度是肯定的。
談談寫博客的初衷:寫博客的時間是我做開發基本1年的時候,說來寫博客也是一個機緣巧合,因為寫博客之前我會經常看一些開源的項目,就比如Github的android-open-project,那麼我每次都是先進Github在搜索android-open-project(我竟然連書簽都懶得保存!),類似的還有很多。。。終於有一天我覺得真麻煩(你是有多遲鈍),所以就把我經常用到的這些網址寫了我的第一篇博客:Android開源與干貨網站匯總,之後存一個書簽。嘗到了這種便捷的好處,就正式開始了CSDN博客之旅。
前幾天碰巧看到一位大神的博客,看了下這位大神堅持寫了近10年的博客,並且每月都有高質量的文章,涉及的知識也是方方面面的。真是震撼了我,那麼向榜樣學習,今年繼續努力,既然開始了就堅持下去。
前言這個是第一次寫源碼分析的文章(僅僅是給自己做個也給自己兩天對volley學習的一個交代吧)。以前的老大經常強調一種代碼閱讀能力(如何通過源碼的閱讀了解框架、流程、及使
android之ListViewListView是android中比較常見並較為復雜的控件之一,它既有默認的模式,又可以實現自定義,通過該控件,可以使UI交互更加多樣化,
今天我們來接觸一個輕輕輕量級數據庫(SQLite),為什麼要加3個輕呢?因為它確實很輕。 Sqlite是專門未嵌入式設備准備的輕量級數據庫,麻雀雖小,五髒俱全,sqlit
這幾天在研究ViewPager,簡單的寫一下如何使用ViewPager實現類似於QQ的“最近聯系人、好友、群組”的界面切換(不知道他們是不是用這個方法實現的)。ViewP