android的mvp

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

android MVP开发模式的优点
1）View和Model之间的耦合度降低，使其更关注自身业务逻辑，结构清晰，维护方便；
2）便于单元测试；
3） 代码复用率提高；
4）代码框架更适用于快速迭代开发；
android MVP开发模式的缺点
1）MVP模式的不足，主要表现在每个view都有presenter ，类相对比较多。
2）写的接口比较多，一个套一个，接手不熟，很容易晕。

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

MVP开发模式的优点：
1.项目结构清晰，解耦程度高，每个功能相互之间独立，可单独测试。

2.代码维护性高，代码出线Bug，能够快速定位。

3.功能扩展性强，增加业务功能时，并不需要去修改原始代码，只需增加相应的业务代码即可。

MVP开发模式的缺点：
1.项目会出现大量的presenter，大大增加了类的数量。
2.因为Activity会持有presenter的引用，使用不当的话，容易出现内存泄露问题。

‘叁’ Android 中 MVC、MVP 和 MVVM 对比

MVC、MVP和MVVM是常见的三种架构设计模式，当前MVP和MVVM的使用相对比较广泛，当然MVC也并没有过时之说。

MVC (Model-View-Controller, 模型-视图-控制器)，标准的MVC是这个样子的：

简述：

缺点：

MVP (Model-View-Presenter) 是MVC的演化版本，几个主要部分如下：

简述：

解释：

优点：

缺点：

MVVM 是 Model-View-ViewModel 的简写。和 MVP 模式相比，MVVM 模式用 ViewModel 替换了 Presenter ，其他层基本上与 MVP 模式一致，ViewModel 可以理解成 是 View 的数据模型和 Presenter 的合体。MVVM 就是将其中的 View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。

简述：

缺点:

参考：

‘肆’ Android UI 架构演进：从 MVC 到 MVP、MVVM、MVI

Android UI架构的演变：从MVC到MVP、MVVM和MVI

随着Android开发的发展，为优化代码设计，业界不断探索和实践不同的架构模式，如MVC、MVP、MVVM和MVI，它们的核心目标是“关注点分离”，以提高代码的可维护性、测试性和可读性。最初，所有UI逻辑都集中在Activity中，导致高度耦合，难以管理。

1. MVC：Android的默认设计，将代码划分为Model、View和Controller，尽管解决了Activity代码过载问题，但Activity仍承担了View和逻辑处理的双重任务，分离不够彻底。

2. MVP：为了解决MVC的不足，MVP将逻辑分离到Presenter，使用Contract接口定义View和Presenter的交互。但双向依赖仍是其缺点。

3. MVVM：MVVM将Presenter变为ViewModel，使用观察者模式减少双向依赖。DataBinding等工具支持了MVVM的实现，但过度使用可能导致数据流混乱。

4. MVI：MVI强调单数据流，通过ViewState简化View和ViewModel之间的交互。虽然更注重响应式，但过度压缩状态可能导致复杂性。

总的来说，MVP、MVVM和MVI都试图将Activity的职责分解，但每种模式都有其局限性和适用场景。MVVM和MVP本质上相似，而MVI则引入了命令式到响应式的转变。选择哪种架构，应根据项目的具体需求和团队习惯来决定，而不是盲目追求新潮。

‘伍’ 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模式的工作了。