前言
MVP作爲一種MVC的演化版本在Android開發中受到了越來越多的關注,但在項目開發中選擇一種這樣的軟件設計模式需保持慎重心態,一旦確定 使用MVP作爲你App的開發模式那麼你就最好堅持做下去,如果在使用MVP模式開發過程中發現問題而且坑越來越大,這時你想用MVC等來重新設計的話基 本上就等於推倒重來了。要知道在Android上MVP在現在爲止並沒有統一的標準或者框架,不像SSH這三個成熟穩重強而有力的三劍客支持推動着 Java EE的開發,所以在運用MVP時一定要做好自己的理解,並且儘量預知自己App各模塊的需求(客戶說改改改,我們就改改改 :-( )以便提前做好充分的設計工作。當然MVP既然能出現那麼必然有它的優點的,不然誰會理會這個冒出來的東西,下面就對Android中MVP做一些闡述。
MVP簡介
相信大家對MVC都是比較熟悉了:M-Model-模型、V-View-視圖、C-Controller-控制器,MVP作爲MVC的演化版本,那麼類似的MVP所對應的意義:M-Model-模型、V-View-視圖、P-Presenter-表示器。 從MVC和MVP兩者結合來看,Controlller/Presenter在MVC/MVP中都起着邏輯控制處理的角色,起着控制各業務流程的作用。而 MVP與MVC最不同的一點是M與V是不直接關聯的也是就Model與View不存在直接關係,這兩者之間間隔着的是Presenter層,其負責調控 View與Model之間的間接交互,MVP的結構圖如下所示,對於這個圖理解即可而不必限於其中的條條框框,畢竟在不同的場景下多少會有些出入的。在 Android中很重要的一點就是對UI的操作基本上需要異步進行也就是在MainThread中才能操作UI,所以對View與Model的切斷分離是 合理的。此外Presenter與View、Model的交互使用接口定義交互操作可以進一步達到鬆耦合也可以通過接口更加方便地進行單元測試。
模型(Model):負責處理數據的加載或者存儲,比如從網絡或本地數據庫獲取數據等;
視圖(View):負責界面數據的展示,與用戶進行交互;
協調者(Presenter):相當於協調者,是模型與視圖之間的橋樑,將模型與視圖分離開來。
Model
模型這一層之中做的工作是具體業務邏輯處理的實現,都伴隨着程序中各種數據的處理,複雜一些的就明顯需要實現一個Interface來鬆耦合了。
View
視圖這一層體現的很輕薄,負責顯示數據、提供友好界面跟用戶交互就行。MVP下Activity和Fragment體現在了這一 層,Activity一般也就做加載UI視圖、設置監聽再交由Presenter處理的一些工作,所以也就需要持有相應Presenter的引用。例 如,Activity上滾動列表時隱藏或者顯示Acionbar(Toolbar),這樣的UI邏輯時也應該在這一層。另外在View上輸入的數據做一些 判斷時,例如,EditText的輸入數據,假如是簡單的非空判斷則可以作爲View層的邏輯,而當需要對EditText的數據進行更復雜的比較時,如 從數據庫獲取本地數據進行判斷時明顯需要經過Model層才能返回了,所以這些細節需要自己掂量。
Presenter
Presenter這一層處理着程序各種邏輯的分發,收到View層UI上的反饋命令、定時命令、系統命令等指令後分發處理邏輯交由Model層做具體的業務操作。
在Android項目中,Activity和Fragment佔據了大部分的開發工作。如果有一種設計模式(或者說代碼結構)專門是爲優化Activity和Fragment的代碼而產生的,你說這種模式重要不?這就是MVP設計模式。
按照MVC的分層,Activity和Fragment(後面只說Activity)應該屬於View層,用於展示UI界面,以及接收用戶的輸入,此外還要承擔一些生命週期的工作。Activity是在Android開發中充當非常重要的角色,特別是TA的生命週期的功能,所以開發的時候我們經常把一些業務邏輯直接寫在Activity裏面,這非常直觀方便,代價就是Activity會越來越臃腫,超過1000行代碼是常有的事,而且如果是一些可以通用的業務邏輯(比如用戶登錄),寫在具體的Activity裏就意味着這個邏輯不能複用了。如果有進行代碼重構經驗的人,看到1000+行的類肯定會有所顧慮。因此,Activity不僅承擔了View的角色,還承擔了一部分的Controller角色,這樣一來V和C就耦合在一起了,雖然這樣寫方便,但是如果業務調整的話,要維護起來就難了,而且在一個臃腫的Activity類查找業務邏輯的代碼也會非常蛋疼,所以看起來有必要在Activity中,把View和Controller抽離開來,而這就是MVP模式的工作了。
MVP模式的核心思想:
MVP把Activity中的UI邏輯抽象成View接口,把業務邏輯抽象成Presenter接口,Model類還是原來的Model。
這就是MVP模式,現在這樣的話,Activity的工作的簡單了,只用來響應生命週期,其他工作都丟到Presenter中去完成。從上圖可以看出,Presenter是Model和View之間的橋樑,爲了讓結構變得更加簡單,View並不能直接對Model進行操作,這也是MVP與MVC最大的不同之處。
MVP模式的作用
- 分離了視圖邏輯和業務邏輯,降低了耦合
- Activity只處理生命週期的任務,代碼變得更加簡潔
- 視圖邏輯和業務邏輯分別抽象到了View和Presenter的接口中去,提高代碼的可閱讀性
- Presenter被抽象成接口,可以有多種具體的實現,所以方便進行單元測試
- 把業務邏輯抽到Presenter中去,避免後臺線程引用着Activity導致Activity的資源無法被系統回收從而引起內存泄露和OOM
-
其中最重要的有三點:
Activity 代碼變得更加簡潔
相信很多人閱讀代碼的時候,都是從Activity開始的,對着一個1000+行代碼的Activity,看了都覺得難受。
使用MVP之後,Activity就能瘦身許多了,基本上只有FindView、SetListener以及Init的代碼。其他的就是對Presenter的調用,還有對View接口的實現。這種情形下閱讀代碼就容易多了,而且你只要看Presenter的接口,就能明白這個模塊都有哪些業務,很快就能定位到具體代碼。Activity變得容易看懂,容易維護,以後要調整業務、刪減功能也就變得簡單許多。
方便進行單元測試
一般單元測試都是用來測試某些新加的業務邏輯有沒有問題,如果採用傳統的代碼風格(習慣性上叫做MV模式,少了P),我們可能要先在Activity裏寫一段測試代碼,測試完了再把測試代碼刪掉換成正式代碼,這時如果發現業務有問題又得換回測試代碼,咦,測試代碼已經刪掉了!好吧重新寫吧……
MVP中,由於業務邏輯都在Presenter裏,我們完全可以寫一個PresenterTest的實現類繼承Presenter的接口,現在只要在Activity裏把Presenter的創建換成PresenterTest,就能進行單元測試了,測試完再換回來即可。萬一發現還得進行測試,那就再換成PresenterTest吧。
避免 Activity 的內存泄露
Android APP 發生OOM的最大原因就是出現內存泄露造成APP的內存不夠用,而造成內存泄露的兩大原因之一就是Activity泄露(Activity Leak)(另一個原因是Bitmap泄露(Bitmap Leak))。
Java一個強大的功能就是其虛擬機的內存回收機制,這個功能使得Java用戶在設計代碼的時候,不用像C++用戶那樣考慮對象的回收問題。然而,Java用戶總是喜歡隨便寫一大堆對象,然後幻想着虛擬機能幫他們處理好內存的回收工作。可是虛擬機在回收內存的時候,只會回收那些沒有被引用的對象,被引用着的對象因爲還可能會被調用,所以不能回收。
Activity是有生命週期的,用戶隨時可能切換Activity,當APP的內存不夠用的時候,系統會回收處於後臺的Activity的資源以避免OOM。
採用傳統的MV模式,一大堆異步任務和對UI的操作都放在Activity裏面,比如你可能從網絡下載一張圖片,在下載成功的回調裏把圖片加載到 Activity 的 ImageView 裏面,所以異步任務保留着對Activity的引用。這樣一來,即使Activity已經被切換到後臺(onDestroy已經執行),這些異步任務仍然保留着對Activity實例的引用,所以系統就無法回收這個Activity實例了,結果就是Activity Leak。Android的組件中,Activity對象往往是在堆(Java Heap)裏佔最多內存的,所以系統會優先回收Activity對象,如果有Activity Leak,APP很容易因爲內存不夠而OOM。
採用MVP模式,只要在當前的Activity的onDestroy裏,分離異步任務對Activity的引用,就能避免 Activity Leak。
MVP模式的使用
上面一張簡單的MVP模式的UML圖,從圖中可以看出,使用MVP,至少需要經歷以下步驟:
- 創建IPresenter接口,把所有業務邏輯的接口都放在這裏,並創建它的實現PresenterCompl(在這裏可以方便地查看業務功能,由於接口可以有多種實現所以也方便寫單元測試)
- 創建IView接口,把所有視圖邏輯的接口都放在這裏,其實現類是當前的Activity/Fragment
- 由UML圖可以看出,Activity裏包含了一個IPresenter,而PresenterCompl裏又包含了一個IView並且依賴了Model。Activity裏只保留對IPresenter的調用,其它工作全部留到PresenterCompl中實現
- Model並不是必須有的,但是一定會有View和Presenter
通過上面的介紹,MVP的主要特點就是把Activity裏的許多邏輯都抽離到View和Presenter接口中去,並由具體的實現類來完成。這種寫法多了許多IView和IPresenter的接口,在某種程度上加大了開發的工作量,剛開始使用MVP的小夥伴可能會覺得這種寫法比較彆扭,而且難以記住。只要在具體項目中多寫幾次,就能熟悉MVP模式的寫法,理解TA的意圖,以及享受其帶來的好處。
MVP模式簡單實例1
一個簡單的登錄界面,點擊LOGIN則進行賬號密碼驗證,點擊CLEAR則重置輸入。
項目結構看起來像是這個樣子的,MVP的分層還是很清晰的。在模塊下面再去創建model、view、presenter的子Package,當然也可以用model、view、presenter作爲頂級的Package,然後把所有的模塊的model、view、presenter類都到這三個頂級Package中,就好像有人喜歡把項目裏所有的Activity、Fragment、Adapter都放在一起一樣。
首先來看看LoginActivity
public class LoginActivity extends ActionBarActivity implements ILoginView, View.OnClickListener {
private EditText editUser;
private EditText editPass;
private Button btnLogin;
private Button btnClear;
ILoginPresenter loginPresenter;
private ProgressBar progressBar;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//find view
editUser = (EditText) this.findViewById(R.id.et_login_username);
editPass = (EditText) this.findViewById(R.id.et_login_password);
btnLogin = (Button) this.findViewById(R.id.btn_login_login);
btnClear = (Button) this.findViewById(R.id.btn_login_clear);
progressBar = (ProgressBar) this.findViewById(R.id.progress_login);
//set listener
btnLogin.setOnClickListener(this);
btnClear.setOnClickListener(this);
//init
loginPresenter = new LoginPresenterCompl(this);
loginPresenter.setProgressBarVisiblity(View.INVISIBLE);
}
@Override
public void onClick(View v) {
switch (v.getId()){
case R.id.btn_login_clear:
loginPresenter.clear();
break;
case R.id.btn_login_login:
loginPresenter.setProgressBarVisiblity(View.VISIBLE);
btnLogin.setEnabled(false);
btnClear.setEnabled(false);
loginPresenter.doLogin(editUser.getText().toString(), editPass.getText().toString());
break;
}
}
@Override
public void onClearText() {
editUser.setText("");
editPass.setText("");
}
@Override
public void onLoginResult(Boolean result, int code) {
loginPresenter.setProgressBarVisiblity(View.INVISIBLE);
btnLogin.setEnabled(true);
btnClear.setEnabled(true);
if (result){
Toast.makeText(this,"Login Success",Toast.LENGTH_SHORT).show();
startActivity(new Intent(this, HomeActivity.class));
}
else
Toast.makeText(this,"Login Fail, code = " + code,Toast.LENGTH_SHORT).show();
}
@Override
public void onSetProgressBarVisibility(int visibility) {
progressBar.setVisibility(visibility);
}
}
從代碼可以看出LoginActivity只做了findView以及setListener的工作,而且包含了一個ILoginPresenter,所有業務邏輯都是通過調用ILoginPresenter的具體接口來完成。所以LoginActivity的代碼看起來很舒爽,甚至有點愉悅呢 。視力不錯的你可能還看到了ILoginView接口的實現,如果不懂爲什麼要這樣寫的話,可以先往下看,這裏只要記住LoginActivity實現了ILoginView接口。
創建接口ILoginPresenter
public interface ILoginPresenter {
void clear();
void doLogin(String name, String passwd);
void setProgressBarVisiblity(int visiblity);
}
實現類LoginPresenterCompl
public class LoginPresenterCompl implements ILoginPresenter {
ILoginView iLoginView;
IUser user;
Handler handler;
public LoginPresenterCompl(ILoginView iLoginView) {
this.iLoginView = iLoginView;
initUser();
handler = new Handler(Looper.getMainLooper());
}
@Override
public void clear() {
iLoginView.onClearText();
}
@Override
public void doLogin(String name, String passwd) {
Boolean isLoginSuccess = true;
final int code = user.checkUserValidity(name,passwd);
if (code!=0) isLoginSuccess = false;
final Boolean result = isLoginSuccess;
handler.postDelayed(new Runnable() {
@Override
public void run() {
iLoginView.onLoginResult(result, code);
}
}, 3000);
}
@Override
public void setProgressBarVisiblity(int visiblity){
iLoginView.onSetProgressBarVisibility(visiblity);
}
private void initUser(){
user = new UserModel("mvp","mvp");
}
}
從代碼可以看出,LoginPresenterCompl保留了ILoginView的引用,因此在LoginPresenterCompl裏就可以直接進行UI操作了,而不用在Activity裏完成。這裏使用了ILoginView引用,而不是直接使用Activity,這樣一來,如果在別的Activity裏也需要用到相同的業務邏輯,就可以直接複用LoginPresenterCompl類了(一個Activity可以包含一個以上的Presenter,總之,需要什麼業務就new什麼樣的Presenter),這也是MVP的核心思想
ILoginView
public interface ILoginView {
public void onClearText();
public void onLoginResult(Boolean result, int code);
public void onSetProgressBarVisibility(int visibility);
}
MVP模式簡單實例2(也是登錄)
MVP登錄實例(無butterKnife)
mvp:也是一種開發方式, 也是分三層 M:模型model javaBean V:視圖view layout+View集合 P:presenter 協調者 線程 邏輯 調用 低耦低:引入三個接口來獲得
比mvc更低的耦合度 分包:使用分層更加清析) 【 耦合度】 :類的引用關係的強弱. (接口引用會比實現類引用耦合度低)
結論:增加接口引用可以降低耦合度
1.分包
- model
- view
- presenter
2.編寫P presenter
包含 邏輯與線程 用來處理用戶對界面的操作
創建ILoginPresenter
public interface ILoginPresenter {
//處理登錄數據
void login(IUser user);
}
接口實現類LoginPresenter
public class LoginPresenter implements ILoginPresenter {
private ILoginView mView;
public LoginPresenter(ILoginView view) {
this.mView = view;
}
//處理登錄數據
@Override
public void login(IUser user) {
//2.1.格式校驗
if (user.isAccountPwdNotEmpty()) {
//進行登錄業務邏輯
//2.2.顯示Loading
mView.showLoading(true);
//2.3.延時處理
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
//2.4.發送參數給服務端 獲取校驗結果
int code = new Random().nextInt(2);
if (code == 0) {
//2.5.調用界面顯示登錄成功
mView.showToast("登錄成功");
} else {
//2.6.調用界面顯示登錄失敗
mView.showToast("賬號密碼出錯");
}
//2.7調用界面隱藏loading
mView.showLoading(false);
}
}, 3000);
} else {
//調用界面進行吐司提示
mView.showToast("賬號密碼不能爲空");
}
}
}
3.編寫 V 界面顯示
ILoginView
public interface ILoginView {
public void showLoading(boolean show) ;
public void showToast(String msg) ;
}
MainActivity
public class MainActivity extends AppCompatActivity implements ILoginView {
private ILoginPresenter loginPresenter;
private ProgressBar pbar;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
pbar = (ProgressBar) findViewById(R.id.pbar);
loginPresenter = new LoginPresenter(this);
}
public void login(View view) {
EditText accountEt= (EditText) findViewById(R.id.account_et);
EditText pwdEt= (EditText) findViewById(R.id.pwd_et);
String inputAccount=accountEt.getText().toString();
String inputPwd=pwdEt.getText().toString();
//調用p進行登錄
loginPresenter.login(new User(inputAccount,inputPwd));
}
@Override
public void showLoading(boolean show) {
pbar.setVisibility(show?View.VISIBLE:View.INVISIBLE);
}
@Override
public void showToast(String msg) {
Toast.makeText(this, msg, Toast.LENGTH_SHORT).show();
}
}
4.編寫 M數據校驗
IUser
public interface IUser {
//格式校驗交給Model
boolean isAccountPwdNotEmpty();
}
實現類User
public class User implements IUser {
public String username;
public String pwd;
public User(String username, String pwd) {
this.username = username;
this.pwd = pwd;
}
//格式校驗交給Model
@Override
public boolean isAccountPwdNotEmpty() {
if (!TextUtils.isEmpty(username) && !TextUtils.isEmpty(pwd)) {
return true;
} else {
return false;
}
}
}
總結:因爲代碼主要邏輯寫到P裏面 得到一個Activity/Fragmnet代碼行數精簡