① 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采用哪种软件设计模式都是为了达到如下目的，找到合适的加以运用就是最好的：易于维护易于测试松耦合度复用性高健壮稳定------------------------------------------------------------------------------------以上内容均参考互联网，希望以上知识对您有所帮助，