androidmvp框架
⑴ Android MVP 开发模式有哪些优缺点
MVP概念：
MVP(Model-View-Presenter) 是总所周知MVC模式的一个演变，主要目的都是划分模块职责，降低模块耦合，易测试,提高代码复用。
层级责任
Model:负责数据的检索,持久化等操作。
View: 负责UI的绘制和用户的交互。
Presenter: 作为Model和View的中间协调部分,负责两者之间的业务逻辑处理。
MVC模式的区别
MVC模式允许View层和Model层直接通讯。
当某个View的功能很复杂的时候,View和Model的耦合度可能会很高。
MVP模式就没有这个问题,View会抽象出来一系列操作UI的接口。
Presenter拿到的都是其他两个层级的接口来做业务逻辑的处理，这样不仅可以使View和Model之间的耦合度降低,还可以更易得进行单元测试。
MVP的优缺点
优点:降低耦合，层级职责更明显，易于单元测试。
缺点:造成类数量爆炸，代码复杂度和学习成本高，在某些场景下presenter的复用会产生接口冗余。
⑵ Android MVP架构中的Presentation层应该怎么设计
对于MVP（Model View Presenter），大多数人都能说出一二：“MVC的演化版本”，“让Model和View完全解耦”等等。本篇博文仅是为了做下记录，提出一些自己的看法，和帮助大家如何针对一个Activity页面去编写针对MVP风格的代码。
对于MVP，我的内心有一个问题：
为何这个模式出来后，就能被广大的Android的程序员接受呢？
问了些程序员，他们对于MVP的普遍的认识是：“代码很清晰，不过增加了很多类”。我在第一次看到MVP的时候，看了一个demo，看完以后觉得非常nice（但是回过头来，自己想个例子写，就头疼写不出来，当然这在后文会说）。nice的原因还是因为，这个模式的确让代码的清晰度有了很大的提升。
那么，提升一般都是对比出来的，回顾下，没有应用MVP的代码结构。很多人说明显是MVC么：
View：对应于布局文件
Model：业务逻辑和实体模型
Controllor：对应于Activity
看起来的确像那么回事，但是细细的想想这个View对应于布局文件，其实能做的事情特别少，实际上关于该布局文件中的数据绑定的操作，事件处理的代码都在Activity中，造成了Activity既像View又像Controller（当然了Data-Binder的出现，可能会让View更像View吧）。这可能也就是为何，在该文中有一句这样的话：
Most of the modern Android applications just use View-Model architecture，everything is connected with Activity.
而当将架构改为MVP以后，Presenter的出现，将Actvity视为View层，Presenter负责完成View层与Model层的交互。现在是这样的：
View 对应于Activity，负责View的绘制以及与用户交互
Model 依然是业务逻辑和实体模型
Presenter 负责完成View于Model间的交互
ok，先简单了解下，文中会有例子到时候可以直观的感受下。
⑶ 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 MVP框架
前言
MVP作为一种MVC的演化版本在Android开发中受到了越来越多的关注，但在项目开发中选择一种这样的软件设计模式需保持慎重心态，一旦确定使用MVP作为你App的开发模式那么你就最好坚持做下去，如果在使用MVP模式开发过程中发现问题而且坑越来越大，这时你想用MVC等来重新设计的话基本上就等于推倒重来了。要知道在Android上MVP在现在为止并没有统一的标准或者框架，不像SSH这三个成熟稳重强而有力的三剑客支持推动着java EE的开发，所以在运用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的交互使用接口定义交互操作可以进一步达到松耦合也可以通过接口更加方便地进行单元测试。
项目效果预览
包图中明显的三层：Model包、Presenter包、UI包，其中，三者都实现各自的结构，Model为WeatherModel、Presenter为WeatherPresenter、View为Weather，那么具体实现类就是impl包里的了，View层的即为Activity。此外的app和util包无关紧要可以不看。可以看到采用MVP设计后项目明显多了很多东西，这也是不可避免的，使用原始方法可以使项目开起来简单些但是以后还有维护呢、测试呢、加功能呢、。。。
entity里的实体属性基本上对应json里的这些属性了，代码不贴了
View里面的接口：
public interface WeatherView {
void showLoading();
void hideLoading();
void showError();
void setWeatherInfo(Weather weather);
}
WeatherPresenter的接口：
public interface WeatherPresenter {
/**
* 获取天气的逻辑
*/
void getWeather(String cityNO);
}
WeatherModel接口：
public interface WeatherModel {
void loadWeather(String cityNO, OnWeatherListener listener);
}
prestener里面还有个OnWeatherListener，其在Presenter层实现，给Model层回调，更改View层的状态，确保Model层不直接操作View层。如果没有这一接口在WeatherPresenterImpl实现的话，WeatherPresenterImpl只有View和Model的引用那么Model怎么把结果告诉View呢？当然这只是一种解决方案，在实际项目中可以使用Dagger、EventBus、Otto等第三方框架结合进来达到更加松耦合的设计。
public interface OnWeatherListener {
/**
* 成功时回调
*
* @param weather
*/
void onSuccess(Weather weather);
/**
* 失败时回调，简单处理，没做什么
*/
void onError();
}
所以demo的代码流程：Activity做了一些UI初始化的东西并需要实例化对应WeatherPresenter的引用和实现WeatherView的接口，监听界面动作，Go按钮按下后即接收到查询天气的事件，在onClick里接收到即通过WeatherPresenter的引用把它交给WeatherPresenter处理。WeatherPresenter接收到了查询天气的逻辑就知道要查询天气了，然后把查询天气的具体业务实现交给WeatherModel去实现同时把WeatherListener即WeatherPresenter自己传给WeatherModel。WeatherModel进行查询天气业务后即把结果通过WeatherListener回调通知WeatherPresenter，WeatherPresenter再把结果返回给View层的Activity，最后Activity显示结果。就这样，拍砖之处请拍。
End
采用哪种软件设计模式都是为了达到如下目的，找到合适的加以运用就是最好的：
易于维护
易于测试
松耦合度
复用性高
健壮稳定
------------------------------------------------------------------------------------
以上内容均参考互联网，希望以上知识对您有所帮助，
⑸ Android真的推荐用MVI模式MVI和MVVM有什么区别
android自己卷自己，自己造一个MVI架构模式吗？
MVI架构模式是国内android开发者最近一两年造出来的吗？
看了很多MVI的资料，发现都提到cycle.js框架。android的mvi架构就是启发于cycle.js框架。
我们再看看Cycle.js框架是什么时候开始的，又是什么时候开始使用MVI模式的。
Cycle.js框架 第一个预发版本 ：
https://github.com/cyclejs/cyclejs/releases?page=6
再结合官方文档来看，Cycle.js框架就是为了MVI架构模式而生的。
虽然不知道，Cycle.js框架是不是首个MVI模式框架。
但是从很多资料可以推测，MVI架构模式就是Cycle.js框架推广开来的。
而且早在2014年就已经在前端开发中用得飞起了。
想想2014年，咱们在干嘛？android在用什么架构模式。
正所谓，天下武功出少林啊。
我们android的很多技术，在前端早就用“烂了”。
我们知道MVP和MVVM的爹都是MVC。MVI的爹也是MVC。
MVC的Controller是命令是编程组件，不能直接实现响应式编程思想。
响应式编程范式（Reactive programming）：
安卓官方的compose框架、微信小程序、Flutter、React、鸿蒙UI的开发框架，都是使用响应式开发框架。
这里就不拓展开来讲了，上面提到的任何一个开发框架，你只要会一个基本就能理解响应式编程范式。
如果一个都不会也没关系，现在不理解响应式编程也没关系，等你学会MVI就理解了，这种只有实际使用过才能深刻理解。
学不会也没关系，不要焦虑（尤其那些工作不久的小伙伴，学不会属于正常现象~）
MVI，咱第一遍学不会，就等2年，再学一遍~
2年后也没学会，那就再等2年~ 一定要有耐心~
如果还是学不会，那也没关系，因为MVI早晚也会过时~ 等过时了就不用学了~
哈哈哈~ 别笑，正经Android可不会开玩笑的。
就像rxjava，当年有多少人死活学不会，android开发现在谁还学Rxjava？哈哈哈~
用一张图来总结这次升级的核心思想：
新版架构指南在旧版的基础上，做了如下调整和建议：
1. 将LiveData组件改成了StateFlow
对协程的使用更友好。并且更能体现面向数据流开发的思想。
实际上，依然使用LiveData也没毛病。
2. ViewModel传递给View的数据限制为View的UIState
ViewModel从Model层获取数据后，转换为UIState数据，通过StateFlow流向View层。
UIState的数据面向界面组件而定义的，是能直接控制View组件如何显示的数据。
所以我们也可以称UIState为界面的状态或者View的状态。
如下：
3. 单数据流还是多数据流的选择
官方指南并没有强制我们使用单流。
同一个界面应该使用单个StateFlow还是多个StateFlow，需要我们自己判断。
我们应该根据UIStates数据们之间关联程度来决定多流还是单流。
单流优缺点都十分明显：
优点： 数据集中管控，会提高代码的可读性和修改的便利性。
缺点： 当数据非常多且复杂时，会影响效率。因为我们没有diff功能，View层不能只更新有变化的数据，只会根据UIState刷新当前界面。
https://developer.android.com/jetpack/guide/ui-layer#additional-considerations
我们再看下官方新版架构图：
当然不仅仅MVVM可以改造成响应式开发范式，MVP也是可以的。
不信你看 这篇blog ：
https://www.raywenderlich.com/817602-mvi-architecture-for-android-tutorial-getting-started
1. 理解MVC架构模式的思想【MVC是其他架构模式之爹，他的思想是MVP、MVVM、MVI的基础，学会它是关键步骤~】。
3. 学习kotlin的StateFlow组件，的使用：Sequence->Flow->StateFlow。
4. 学习ViewModel组件的使用（虽然不用ViewModel也能实现MVI架构，但是ViewModel还是值得学习）。
5. 理解DRY（Don't Repeat Yourself）原则。
6. 理解MVVM（因为官方的MVI模式是基于MVVM的基础改造的~）。
7. 学习官方架构指南。
8. 实战。
在这里就分享一份由大佬亲自收录整理的 学习PDF+架构视频+面试文档+源码笔记 ， 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料
这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理，帮助大家在未来取得一份不错的答卷。
当然，你也可以拿去查漏补缺，提升自身的竞争力。
真心希望可以帮助到大家，Android路漫漫，共勉！
如果你有需要的话，只需 私信我【进阶】即可获取