简单聊聊 Android MVP 模式

在 Android 应用开发的早期，那时几乎是一个野蛮生长的时期，整体的架构没有得到好的重视，代码不能做到重用，大量的复制粘贴，导致代码维护变得异常的棘手。随着多年来技术的发展和积累，在踩了无数个坑之后，Android 应用开发的 UI 框架模式目前形成了两套主流的模式，MVP 和 MVVM。近些年，MVP 模式受到热捧，虽然没有像开发 React 一样，redux 和 mobx 几乎成了其必选其一的情况。
UI 架构模式是面向开发者的，它在一定程度上还是会存在性能的顺号，但好处是代码具有更高的可阅读性、可测试性、可维护性、以及可复用性。

MVP 的基本概念

传统的 Android 应用开发中，View 层(Activity，Fragment 或者 自定义 View) 承载太多责任，不仅要完成界面的更新、动画的渲染等 UI 相关的操作，还要处理如从网络获取数据、将数据保存到本地数据库等各种业务逻辑操作，由于职责不单一，View 层的代码往往显得很庞大，一个 Activity 或者 Fragment 的代码行数可能要超过好几千行。这种模式显示不是长久之计，随着一个类的代码量逐渐增加，维护和升级将变得越来越困难，牵一发而动全身。回想其之前维护的一个项目便是如此，所以稍微复杂的页面就会出现上千行的代码，稍微改几行代码就可能引起雪崩式的崩溃。为了更好的组织并对代码进行分层设计，我们在后续的新项目中引入了 MVP 模式。
MVP 的全称是Model、View、Presenter，顾名思义，它将整个应用分为三层。

• View 层：视图层，包含界面相关的功能，例如各种 Activity，Fragment、VIew、Adapter 等，专注于用户的交互，实现设计师给出的界面，动画等交互效果。View 层一般会持有 Presenter 层的应用，并将非 UI 的逻辑操作委托给 Presenter。
• Presenter 层：逻辑控制层，充当中间人的角色，用来隔离 View 层 和 Model 层，该层是通过从 View 层剥离控制逻辑部分而形成的，主要负责 View 层 和 Model 层的控制和交互。例如接收 View 层的网络数据加载请求，并分发给对应的 Model 处理，同时监听 Model 层的处理结果，最终将其反馈给 View 层，从而实现界面的更新。
• Mode 层：封装各种数据来源，如远程网络数据，本地数据库数据，对 Presenter 层提供简单易用的接口。

MVP 和 MVC 的区别

MVP 是 MVC 的延伸和改进。主要有以下区别。

• MVP 中 View 层和 Model 层并没有直接通信，而是通过中间人 Presenter 来间接通信。Presenter 和 View 以及 Model 的交互都是通过接口进行的，通常 View 和 Presenter 是一对一的，当然，复杂的 View 可能需要多个 Presenter 来共同处理。
• MVC 中 Model 层和 VIew 层是直接通信的，而且 Controller 是基于行为的，可以被多个 View 共享。

MVP 的好处

使用 MVP 组织代码架构，并对代码实施分层管理，可以带来很多好处。

• 如果界面发生变化，甚至是推翻原先的设计重新来过，只需要修改对应的 View 即可，Presenter 和 Model 层无需改动。
• 如果业务逻辑或者数据获取方式改变，只需要修改对应的 Model。
• 如果控制逻辑发生改变，只需要修改赌赢的 Presenter。
• Presenter 层和 VIew 层以及 Model 层的交互都是基于接口实现的，这有助于对 Presenter 进行单元测试，同时由于是面向接口变成，只需要实现定义好接口，每一层的实现可以交由不同的开发人员并行实现，并最终联调，能够加快功能的实现。
• 团队的新成员拿到项目的代码，能够很容易的读懂现有的逻辑，快速上手。

MVP 存在的问题

• 增加代码类的数量。
• 由于进项了三层划分，函数的调用栈变深了，所以就需要开发人员清楚的明白哪一层具体负责哪些功能，哪些代码应该在哪个层，如果因为层次职责认不清等原因导致不同层的代码乱入，从而没有达到 MVP 充分解耦各层的目的。