Android MVP 开发模式有哪些优缺点

一、Android MVP 开发模式有哪些优缺点

1、MVP(Model-View-Presenter)是总所周知MVC模式的一个演变，主要目的都是划分模块职责，降低模块耦合，易测试,提高代码复用。

2、Model:负责数据的检索,持久化等操作。

3、View:负责UI的绘制和用户的交互。

4、Presenter:作为Model和View的中间协调部分,负责两者之间的业务逻辑处理。

5、MVC模式允许View层和Model层直接通讯。

6、当某个View的功能很复杂的时候,View和Model的耦合度可能会很高。

7、MVP模式就没有这个问题,View会抽象出来一系列操作UI的接口。

8、Presenter拿到的都是其他两个层级的接口来做业务逻辑的处理，这样不仅可以使View和Model之间的耦合度降低,还可以更易得进行单元测试。

9、优点:降低耦合，层级职责更明显，易于单元测试。

10、缺点:造成类数量爆炸，代码复杂度和学习成本高，在某些场景下presenter的复用会产生接口冗余。

二、android mvp是什么意思

1、MVP模式是MVC模式在Android上的一种变体，要介绍MVP就得先介绍MVC。在MVC模式中，Activity应该是属于View这一层。而实质上，它既承担了View，同时也包含一些Controller的东西在里面。这对于开发与维护来说不太友好，耦合度大高了。把Activity的View和Controller抽离出来就变成了View和Presenter，这就是MVP模式。

2、在Android项目中，Activity和Fragment占据了大部分的开发工作。如果有一种设计模式（或者说代码结构）专门是为优化Activity和Fragment的代码而产生的，你说这种模式重要不？这就是MVP设计模式。

3、按照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开发一般都使用什么框架

开发框架方面包含基本的应用功能开发、数据存储、网络访问这三大块：

一般而言一个标准的Android程序由如下4部分组成即Activity、Broadcast Intent Receiver、Service、Content Provider： 1. Activity是最频繁、最基本的模块，在Android中，一个Activity就是手机上一屏，相当于一个网页一样，所不同的是，每个Activity运行结束了，有个返回值，类似一个函数一样。Android系统会自动记录从首页到其他页面的所有跳转记录并且自动将以前的Activity压入系统堆栈，用户可以通过编程的方式删除历史堆栈中的Activity Instance。

Activity类中主要是跟界面资源文件关联起来（res/layout目录下的xml资源，也可以不含任何界面资源），内部包含控件的显示设计、界面交互设计、事件的响应设计以及数据处理设计、导航设计等application设计的方方面面。 2. Broadcast Intent Receiver

Intent提供了各种不同Activity进行跳转的机制，譬如如果从A activity跳转到B activity，使用Intent来实现如下： Intent in= new Intent(A.this, B.class); startActivity(in);

BroadcastReceiver提供了各种不同的Android应用程序进行进行进程间通讯的机制，譬如当电话呼叫来临时，可以通过BroadcastReceiver发布广播消息。对于用户而言，BroadcastReceiver是不透明的，用户无法看到这个事件，BroadcastReceiver通过NotificationManager来通知用户这些事件发生了，它既可以在资源AndroidManifest.xml中注册，也可以在代码中通过Context.registerReceiver()进行注册，只要是注册了，当事件来临的时候，即时程序没有启动，系统也在需要的时候会自动启动此应用程序；另外各应用程序很方便地通过Context.sendBroadcast()将自己的事情广播给其他应用程序；

3. Service,跟Windows当中的Service完全是一个概念，用户可以通过startService(Intent service)启动一个Service，也可通过Context.bindService来绑定一个Service.

4. Content Provider，由于Android应用程序内部的数据都是私有的，Content Provider提供了应用程序之间数据交换的机制，一个程序可以通过实现一个ContentProvider的抽象接口将自己的数据暴露出去，并且隐蔽了具体的数据存储实现，标准的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的接口，并且实现了权限机制，保护了数据交互的安全性；一个标准的Android应用程序的工程文件包含如下几大部分：-> Java源代码部分(包含Activity)，都在src目录当中；

-> R.java文件，这个文件是Eclipse自动生成与维护的，开发者不需要修改，提供了Android对的资源全局索引；-> Android Library，这个是应用运行的Android库；

-> assets目录，这个目录里面主要用与放置多媒体等一些文件；

-> res目录，放置的是资源文件,跟VC中的资源目录基本类似，其中的drawable包含的是图片文件，layout里面包含的是布局文件，values目录里面主要包含的是字符串(strings.xml)、颜色（colors.xml)以及数组（arrays.xml)资源；

-> AndroidManifest.xml，这个文件异常重要，是整个应用的配置文件，在这个文件中，需要声明所有用到的Activity、Service、Receiver等。