① android MVP解釋！，
優點：view由Activity承擔，Presenter做業務，結構清晰（模式么就是講究一個套路，結構清晰後來者維護也是受益的）。之前開發都是全寫一個類-Activity裡面，業務復雜的情況下看著頭疼。看一些公司招android還講究mvc，™Activity到底算v還是c，還是兩者都是？缺點：每個view有個presenter，類多了。不說presenter重用，實際工作中我是沒法抽象使得presenter重用（技術渣）。有時候業務簡單就直接一個Activity搞定了。
② android mvp模式判斷放哪裡
著作權歸作者所有。 幾乎所有的思想都是為了解耦，提高維護性。 解耦可在生產中實際效果是，把一個大工程，拆分成多個小工程，每個工程之間功能相互獨立，可單獨測試。這樣的好處是把單線程變成多線程，原來需要一個人做一年的工作量，現在可以拆成12個人來做，一個月就能做完。而且每個人都只專注於自己那部分，對於大項目，或者工期緊的項目是非常重要的。要掌握好度，對於十分簡單的功能，也要分的稀碎，就有點過度設計之嫌了。 另一方面提高了維護性，就是容易區分邊界，一旦出了問題，能立刻定位是哪個模塊，哪個介面出了問題。責成相關責任人去修改。 功能模塊化，容易寫測試用例。如果你寫的話。╮(╯_╰)╭ 功能模塊化，讓接手的人更佳容易理解你的思路，工作交接什麼的更順利。 最大的好處是，讓你自己的思路更清晰。不至於自己的代碼，兩天後再來看就成了"別人的代碼"了。 優秀的命名規則加上好的介面設計，可以寫很少的注釋，別人也能輕易讀懂。即便某一模塊讀不懂，也能知道，這個模塊實現了這個功能，先放一放，以後回來再看，不影響擼清業務邏輯。 不要嫌棄代碼量多。因為有些公司可能按代碼量算工資噢（偽）。 我剛接觸編程時候，第一門語言是C，指哪打哪。後來剛接觸C++的面相對象編程思想後，也有過和題主一樣的想法，完全就是把簡單的事情搞復雜了好嗎。。。直到看完馬士兵老師的java教程後。深入理解面相對象的意義，才發現，面相對象簡直是上帝創世一樣牛逼的思想啊！ 題主要是想往高級語言發展，這條路是必須要經歷的，多多練習吧！ 手機打字，想到哪裡說哪裡。湊合看吧。
③ android mvp是什麼意思
MVP模式是MVC模式在Android上的一種變體，要介紹MVP就得先介紹MVC。在MVC模式中，Activity應該是屬於View這一層。而實質上，它既承擔了View，同時也包含一些Controller的東西在裡面。這對於開發與維護來說不太友好，耦合度大高了。把Activity的View和Controller抽離出來就變成了View和Presenter，這就是MVP模式。
在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模式的工作了。
④ android mvp m層主要是處理請求嗎
MVP（Model
View
Presenter）模式是著名的MVC（Model
View
Controller）模式的進化版本。
MVP模式：
1.
View:View通常來說是由Activity實現的，它會包含一個Presenter的引用，View要做的就只是在每次有介面調用的時候（比如按鈕點擊後）調用Presenter的方法。
2.
Model:業務邏輯和實體模型
3.
Presenter：主要作為溝通View和Model的橋梁，它從Model層檢索數據後，返回給View層，但是不像MVC結構，因為它也可以決定與View層的交互操作。
MVC模式：
1.
View：對應於布局文件
2.
Model：業務邏輯和實體模型
3.
Controller：控制器，Android中對應於Activity
在MVP模式中，View和Model的交互是需要Presenter來當作一個跳板。Model層負責的就是業務邏輯實現和請求結果回調，實體類也包括在其中。
⑤ Android 開發問題
Model：實體層，負責獲取實體數據。可詳讀下文。
MVP模式簡單講解，通俗易懂
http://www.apkbus.com/blog-822715-64235.html
Android架構篇－－MVP模式的介紹篇
http://www.apkbus.com/blog-866962-68049.html
⑥ 如何利用mvp架構實現viewpager
MVP所對應的意義：M-Model-模型、V-View-視圖、P-Presenter-表示器。
View
View通常來說就是有Activity、Fragment實現的，View會包含一個或多個Presenter的引用來滿足視圖的業務邏輯。View和Presenter的交互是雙向的，即View層可以調用Presenter的邏輯方法，Presenter也可以控制View的顯示。
Presenter
Presenter作為Model和View的橋梁，負責從Model拿到數據進行處理並返回給View。但Presenter和其他兩層的溝通是通過介面協議進行的，所以每個Presenter中通常會包涵一個或多個介面協議。
Model 和MVC一樣，作為數據倉庫只負責對APP數據進行處理。 Android開發MVP模式實踐中的示例將APP分為以下四層。
Entities:APP中的業務類。 Use Cases:負責從將Entities中的數據進行處理和包裝。 Presenters:從Use
Cases獲取處理好的數據，然後根據需求邏輯為UI提供合適的數據。 UI:從Presenters獲取處理好的最終數據，和用戶進行直接交互。
這四層設計的原則是代碼調用只能從外圓向內圓擴展，內圓不能幹預也不需關心外圓的功能邏輯，這符合MVP的思想，Use
Cases和Presenters將Entities和UI間隔分離，從而使Entities和UI只需關心自身邏輯，數據處理完全交給其他兩層。
這里，有些同學可能會有疑問，說好的Presenters為什麼會有Use
Cases出來攪局？其實這也是我選擇這個工程當做示例的目的，看了好多MVP文章，都在講Presenter如何通過介面協議和其他兩層進行交互，但大都忽略了Presenter層自身的構架，因為僅僅套用MVP模式，雖然在一定程度上降低View的耦合度，但因為Presenter既要處理數據，又要結合需求控制UI交互，所以很可能出現Presenter邏輯的冗餘。後文的示例工程在Presenter和Model之間包裝了Use
Cases，將數據邏輯處理交給UseCases從而讓Presenter更專心於UI交互。
NO1、新建VIew公共部分介面：
/**
*CreatedbyBlueskyon2015/8/27.
*MVP中V層的公共介面
*/
publicinterfaceIView{
publicvoidshowProgressPar();
publicvoidhideProgressPar();
publicvoidshowError(Objecto);
}
View繼承公共IView介面
/**
*CreatedbyBlueskyon2015/8/27.
*登錄View介面
*/
{
publicvoidshowSuccess(Objecto);
}
NO2、VIew的實現。也就是Activity實現ILogin介面：
/**
*登錄頁面Activity
*/
{
;
privateUsermUser;
privateProgressDialogmDialog;
@Override
protectedvoidonCreate(BundlesavedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mPresenter=newLoginPresenter(this);
mUser=newUser();
initVIew();
}
privatevoidinitVIew(){
finalEditTextpwd=(EditText)findViewById(R.id.pwd);
finalEditTextname=(EditText)findViewById(R.id.name);
ButtonloginBtn=(Button)findViewById(R.id.login_btn);
loginBtn.setOnClickListener(newView.OnClickListener(){
@Override
publicvoidonClick(Viewview){
mUser.setName(name.getText().toString());
mUser.setPassword(pwd.getText().toString());
mPresenter.login(mUser);
}
});
}
@Override
(Menumenu){
//Inflatethemenu;.
getMenuInflater().inflate(R.menu.menu_main,menu);
returntrue;
}
@Override
(MenuItemitem){
//Handleactionbaritemclickshere.Theactionbarwill
///Upbutton,solong
//.xml.
intid=item.getItemId();
//
if(id==R.id.action_settings){
returntrue;
}
returnsuper.onOptionsItemSelected(item);
}
@Override
publicvoidshowSuccess(Objecto){
Useruser=(User)o;
Toast.makeText(this,"登錄成功信息："+user.getName()+"/"+user.getPassword(),Toast.LENGTH_LONG).show();
}
@Override
publicvoidshowProgressPar(){
mDialog=newProgressDialog(MainActivity.this);
mDialog.setMessage("正在載入...");
mDialog.show();
}
@Override
publicvoidhideProgressPar(){
mDialog.hide();
}
@Override
publicvoidshowError(Objecto){
Toast.makeText(this,"異常："+((Exception)o).getMessage(),Toast.LENGTH_LONG).show();
}
}
activity的xml布局：
<LinearLayoutxmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
tools:context=".MainActivity"
>
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="@string/hello_world"/>
<EditText
android:id="@+id/name"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="請輸入用戶名"
/>
<EditText
android:id="@+id/pwd"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="請輸入密碼"
/>
<Button
android:id="@+id/login_btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="登錄"/>
</LinearLayout>
No3、新建LoginPresenter。我們面向介面編程，所以，新建一個Presenter介面，在該Demo是沒有什麼方法，這是為了可擴展性考慮。 presenter介面
/**
*CreatedbyBlueskyon2015/8/27.
*MVP中P層
*/
publicinterfacePresenter{
}
登錄presenter實現presenter介面，在這里進行View和Model層橋梁連接，進行業務調度，起到指揮作用
/**
*CreatedbyBlueskyon2015/8/27.
*/
{
privateILoginmLoginView;
privateILoginBizmLoginBiz;
privateHandlermHandler=newHandler();
publicLoginPresenter(ILoginmLoginView){
this.mLoginView=mLoginView;
this.mLoginBiz=newLoginBizImpl();
}
/**
*登錄
*
*@paramo
*/
publicvoidlogin(Objecto){
mLoginView.showProgressPar();
mLoginBiz.login(o,newListener(){
@Override
publicvoidcomplete(){
mHandler.post(newRunnable(){
@Override
publicvoidrun(){
mLoginView.hideProgressPar();
}
});
}
@Override
publicvoidonSuccess(finalObjecto){
mHandler.post(newRunnable(){
@Override
publicvoidrun(){
mLoginView.showSuccess(o);
}
});
}
@Override
publicvoidonFailed(finalExceptione){
mHandler.post(newRunnable(){
@Override
publicvoidrun(){
mLoginView.showError(e);
}
});
}
});
}
}
No4、Model層進行業務邏輯處理。新建model層介面，然後實現業務邏輯處理，做非同步處理及子線程和主線程通訊。 model介面：
/**
*CreatedbyBlueskyon2015/8/27.
*/
publicinterfaceILoginBiz{
publicvoidlogin(Objecto,Listenerlistener);
}
model實現：
/**
*CreatedbyBlueskyon2015/8/27.
*/
{
@Override
publicvoidlogin(Objecto,finalListenerlistener){
finalUseruser=(User)o;
newThread(newRunnable(){
@Override
publicvoidrun(){
try{
Thread.sleep(2*1000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
listener.complete();
if(user.getName().equals(user.getPassword())){//成功
listener.onSuccess(user);
}else{//失敗
listener.onFailed(newException("運行異常..."));
}
}
}).start();
}
}
實體類：
/**
*CreatedbyBlueskyon2015/8/27.
*/
{
privateStringname;
privateStringpassword;
publicStringgetPassword(){
returnpassword;
}
publicvoidsetPassword(Stringpassword){
this.password=password;
}
publicStringgetName(){
returnname;
}
publicvoidsetName(Stringname){
this.name=name;
}
}
回調介面：
/**
*CreatedbyBlueskyon2015/8/27.
*/
publicinterfaceListener{
publicvoidcomplete();
publicvoidonSuccess(Objecto);
publicvoidonFailed(Exceptione);
}
⑦ Android MVP模式中，一個Activity對應多個Presenter時該怎樣抽象
View 和 Presenter 之間是有協議約束的.
假設現有V1, P1, V2, P2, 一個ActivityA對應了P1/P2的功能, 也應該說明它實現了V1/V2介面, 此時應該有PresenterA 實現了P1, P2. 這就是完整的VP的協議就對上了.
這里既然多個頁面可能用到同樣的功能, 最簡單的方式節點使用多繼承(一個Persenter實現ABCD四個介面), 這樣不管Activity實際上用的都是同一個Persenter.如果確定現在已經有實現了, 按樓上的方法實現一個代理就可以了.
實在要實現多個Presenter的話, 可以定義幾個不同的類, 來支持不同多個Presenter的擴展:
class BaseMvpActivity1<P> extent BaseActivity {
P presenter;
}
class BaseMvpActivity2<P1, P2> extent BaseActivity {
P1 presenter1;
P2 presenter2;
}
但不推薦這樣做(失去抽象, 違反依賴倒置原則); 更不推薦使用數組或List(基類使用泛型方便編譯器檢查, 數組或List在具體使用時需要做類型的強轉)
⑧ 如何實現自己的Android MVP框架
前言MVP作為一種MVC的演化版本在Android開發中受到了越來越多的關注，但在項目開發中選擇一種這樣的軟體設計模式需保持慎重心態，一旦確定使用MVP作為你App的開發模式那麼你就最好堅持做下去，如果在使用MVP模式開發過程中發現問題而且坑越來越大，這時你想用MVC等來重新設計的話基本上就等於推倒重來了。要知道在Android上MVP在現在為止並沒有統一的標准或者框架，不像SSH這三個成熟穩重強而有力的三劍客支持推動著JavaEE的開發，所以在運用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的交互使用介面定義交互操作可以進一步達到松耦合也可以通過介面更加方便地進行單元測試。MVP結構圖MVP之ModelModel是用戶界面需要顯示數據的抽象，也可以理解為從業務數據（結果）那裡到用戶界面的抽象（Businessrule,dataaccess,modelclasses）。本文Demo為了簡單處理就直接把業務放到了對應的Model之中。MVP之View視圖這一層體現的很輕薄，負責顯示數據、提供友好界面跟用戶交互就行。MVP下Activity和Fragment體現在了這一層，Activity一般也就做載入UI視圖、設置監聽再交由Presenter處理的一些工作，所以也就需要持有相應Presenter的引用。例如，Activity上滾動列表時隱藏或者顯示Acionbar（Toolbar），這樣的UI邏輯時也應該在這一層。另外在View上輸入的數據做一些判斷時，例如，EditText的輸入數據，假如是簡單的非空判斷則可以作為View層的邏輯，而當需要對EditText的數據進行更復雜的比較時，如從資料庫獲取本地數據進行判斷時明顯需要經過Model層才能返回了，所以這些細節需要自己掂量。MVP之PresenterPresenter這一層處理著程序各種邏輯的分發，收到View層UI上的反饋命令、定時命令、系統命令等指令後分發處理邏輯交由業務層做具體的業務操作，然後將得到的Model給View顯示。演示demo動手寫起代碼來才有更好的感覺。demo很簡單,還是上個圖更直觀，輸入城市的代號，點擊按鈕獲取城市的天氣信息然後顯示出來，網路操作使用Volley框架，解析用Gson，其它的就手寫了。整個項目的包設計如下：包結構項目效果預覽包圖中明顯的三層：Model包、Presenter包、UI包，其中，三者都實現各自的結構，Model為WeatherModel、Presenter為WeatherPresenter、View為Weather，那麼具體實現類就是impl包里的了，View層的即為Activity。此外的app和util包無關緊要可以不看。可以看到採用MVP設計後項目明顯多了很多東西，這也是不可避免的，使用原始方法可以使項目開起來簡單些但是以後還有維護呢、測試呢、加功能呢、。。。entity里的實體屬性基本上對應json里的這些屬性了，代碼不貼了View裡面的介面：publicinterfaceWeatherView{voidshowLoading();voidhideLoading();voidshowError();voidsetWeatherInfo(Weatherweather);}WeatherPresenter的介面：{/***獲取天氣的邏輯*/voidgetWeather(StringcityNO);}WeatherModel介面：publicinterfaceWeatherModel{voidloadWeather(StringcityNO,OnWeatherListenerlistener);}prestener裡面還有個OnWeatherListener，其在Presenter層實現，給Model層回調，更改View層的狀態，確保Model層不直接操作View層。如果沒有這一介面在WeatherPresenterImpl實現的話，WeatherPresenterImpl只有View和Model的引用那麼Model怎麼把結果告訴View呢？當然這只是一種解決方案，在實際項目中可以使用Dagger、EventBus、Otto等第三方框架結合進來達到更加松耦合的設計。{/***成功時回調**@paramweather*/voidonSuccess(Weatherweather);/***失敗時回調，簡單處理，沒做什麼*/voidonError();}所以demo的代碼流程：Activity做了一些UI初始化的東西並需要實例化對應WeatherPresenter的引用和實現WeatherView的介面，監聽界面動作，Go按鈕按下後即接收到查詢天氣的事件，在onClick里接收到即通過WeatherPresenter的引用把它交給WeatherPresenter處理。WeatherPresenter接收到了查詢天氣的邏輯就知道要查詢天氣了，然後把查詢天氣的具體業務實現交給WeatherModel去實現同時把WeatherListener即WeatherPresenter自己傳給WeatherModel。WeatherModel進行查詢天氣業務後即把結果通過WeatherListener回調通知WeatherPresenter，WeatherPresenter再把結果返回給View層的Activity，最後Activity顯示結果。就這樣，拍磚之處請拍。End採用哪種軟體設計模式都是為了達到如下目的，找到合適的加以運用就是最好的：易於維護易於測試松耦合度復用性高健壯穩定------------------------------------------------------------------------------------以上內容均參考互聯網，希望以上知識對您有所幫助，