androidmvp模式
‘壹’ android mvp模式判断放哪里
着作权归作者所有。 几乎所有的思想都是为了解耦，提高维护性。 解耦可在生产中实际效果是，把一个大工程，拆分成多个小工程，每个工程之间功能相互独立，可单独测试。这样的好处是把单线程变成多线程，原来需要一个人做一年的工作量，现在可以拆成12个人来做，一个月就能做完。而且每个人都只专注于自己那部分，对于大项目，或者工期紧的项目是非常重要的。要掌握好度，对于十分简单的功能，也要分的稀碎，就有点过度设计之嫌了。 另一方面提高了维护性，就是容易区分边界，一旦出了问题，能立刻定位是哪个模块，哪个接口出了问题。责成相关责任人去修改。 功能模块化，容易写测试用例。如果你写的话。╮(╯_╰)╭ 功能模块化，让接手的人更佳容易理解你的思路，工作交接什么的更顺利。 最大的好处是，让你自己的思路更清晰。不至于自己的代码，两天后再来看就成了"别人的代码"了。 优秀的命名规则加上好的接口设计，可以写很少的注释，别人也能轻易读懂。即便某一模块读不懂，也能知道，这个模块实现了这个功能，先放一放，以后回来再看，不影响撸清业务逻辑。 不要嫌弃代码量多。因为有些公司可能按代码量算工资噢（伪）。 我刚接触编程时候，第一门语言是C，指哪打哪。后来刚接触C++的面相对象编程思想后，也有过和题主一样的想法，完全就是把简单的事情搞复杂了好吗。。。直到看完马士兵老师的java教程后。深入理解面相对象的意义，才发现，面相对象简直是上帝创世一样牛逼的思想啊！ 题主要是想往高级语言发展，这条路是必须要经历的，多多练习吧！ 手机打字，想到哪里说哪里。凑合看吧。
‘贰’ 如何理解android mvp模式中的interactor
Presenter起到的其实就是一个粘合剂的角色。
它调度了UI逻辑和数据逻辑，然而UI逻辑和数据逻辑的具体实现，Presenter是不用关心的，只需要处理好如何调度，和状态处理即可。
理解这个之前，你需要理解Model 和 ViewModel，一个Model也就是我们平常说的JavaBean，例如一个User类，它有自己的基本属性。姓名，年龄，用户名，密码等等。
而ViewModel代表的是视图的Model，例如一个登陆视图，它的ViewModel包含用户名，密码。
所以Model是不能直接被视图使用的，我们需要转换成ViewModel的形式，然后绑定到视图上。
你可能会说，我也可以直接绑定Model的属性到View上，但是这样View和Model就不是相互独立的了，也就违背了我们使用MVP、MVVM的初衷。
Interactor的作用实际上就是获取Model(从本地数据库，或者是服务器),转换成ViewModel，回调通知把ViewModel传递给Presenter。
Presenter实现了Interactor的回调接口，可以接收到ViewModel的实例，此时它在回调函数里面只需要将接收到的ViewModel绑定的View上面即可。
可以看到，在这个过程中Presenter并没有触及到具体的实现，只是把View 和 ViewModel进行了绑定而已。
当然你也可以把数据逻辑写在Presenter，但是Interactor就不存在了，其实Interactor也是可以重用的
‘叁’ 如何看待android mvp 设计模式的优缺点
MVP设计模式是为了方便ASP.
‘肆’ Android MVP解释！，
优点：view由Activity承担，Presenter做业务，结构清晰（模式么就是讲究一个套路，结构清晰后来者维护也是受益的）。之前开发都是全写一个类-Activity里面，业务复杂的情况下看着头疼。看一些公司招android还讲究mvc，™Activity到底算v还是c，还是两者都是？缺点：每个view有个presenter，类多了。不说presenter重用，实际工作中我是没法抽象使得presenter重用（技术渣）。有时候业务简单就直接一个Activity搞定了。
‘伍’ 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 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 MVP 开发模式有哪些优缺点
androidMVP开发模式的优点1）View和Model之间的耦合度降低，使其更关注自身业务逻辑，结构清晰，维护方便；2）便于单元测试；3）代码复用率提高；4）代码框架更适用于快速迭代开发；androidMVP开发模式的缺点任何开发模式都是有利也有弊的，毕竟世间完美的事物还是少见的。上面提到了MVP模式的有点，那就不得不说其还存在的缺点，或者说不足更准确吧。MVP模式的不足，主要表现在每个view都有presenter，类相对比较多。
‘捌’ 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模式的工作了。
‘玖’ 我是觉得mvp不适合android，增加那么多接口，虽然能解耦，但实际情况是改动一点需求就要涉及好
我今天在研究MVVM你要不要一起啊。你说的是
复杂的业务同时会导致presenter层太大，代码臃肿的问题。
MVVM为MVP升级版哇，有空研究一下子。网页链接