Android学习笔记之MVP框架模式

2020-05-28  本文已影响0人  sssssss_

前言

在学习了 MVC 架构之后,发现 Activity 和 Fragment 和 XML 界面的开发就是典型的 MVC 架构模式,在 Activity 中不仅要处理 UI 操作,还要处理请求数据的操作。

然而在我接触到的开发项目中,看到一个 Activity 中的代码行数接近上千行是常态。在修改的过程中经常要在类里面不断的翻上翻下的,修改起来也非常费劲。

这样就导致了 MVC 架构模式耦合度太高、职责不明确,不易于维护的原因,这次就来学习 MVC 的演变出来的 MVP 架构模式。

MVC 的工作原理: MVC 即 Model View Controller,简单来说就是通过 Controller 的控制去操作 Model 层的数据,并且返回给 View 层展示。当用户触发事件的时候,View 层会发送指令到 Controller 层,接着 Controller 去通知 Model 层更新数据,Model 层更新完数据以后直接显示在 View 层上,这就是 MVC 的工作原理。

MVP是什么

MVP 的全称是 Model-View-Presenter,MVP 是 MVC 的一种演进版本,将 MVC 中的 Controller 改为了 Presenter,View 通过接口与 Presenter 进行交互,有效降低 View(Activity / Fragment) 的复杂性,避免业务逻辑被塞进 View 中,使得 View 变得臃肿。

另外,MVP 模式会解除 View 与 Model 的耦合,同时又带来了良好的可扩展性、可测试性,保证了系统的整洁性、灵活性。虽然在简单的应用中可能会因为各种接口变得复杂,但在稍有规模的应用中,依然能保持结构的整洁和灵活。

MVP的结构

mvp.jpg

在通常开发中,View是指 Activity / Fragment,不过,Presenter 和 Activity 通过定义一个 view 接口进行关联,而 Presenter 和 Model 是通过 Callback 接口进行关联。

  • View接口:显示提示框、数据更新;
  • Callback接口:请求数据时反馈状态(成功、失败和异常等等);
mvp.png

MVP的优缺点

优点

  1. 分离了视图逻辑和业务逻辑,降低了耦合

  2. Activity 只处理生命周期的任务,代码变得更加简洁

  3. 视图逻辑和业务逻辑分别抽象到了 View 和 Presenter 的接口中去,提高代码的可阅读性

  4. Presenter 被抽象成接口,可以有多种具体的实现,所以方便进行单元测试

  5. 把业务逻辑抽到 Presenter 中去,避免后台线程引用着 Activity 导致 Activity 的资源无法被系统回收从而引起内存泄露

  6. Presenter 代码可复用,一个 Presenter 可以用于多个 View,而不需要更改 Presenter 的逻辑。

缺点

  1. Presenter 中除了应用逻辑以外,还有大量的 View->Model,Model->View 的手动同步逻辑,造成 Presenter 比较笨重,维护起来会比较困难。

  2. 由于对视图的渲染放在了 Presenter 中,所以视图和 Presenter 的交互会过于频繁。

  3. 如果 Presenter 过多地渲染了视图,往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更,那么 Presenter 也需要变更了。

  4. 额外的代码复杂度及学习成本。

MVP 和 MVC 的区别

MVP 与 Activity、Fragment 的生命周期

  • 问题原因:由于 Model 在进行异步操作,例如请求网络数据,Presenter 持有 Activity 的强引用,如果在请求结束之前使得 Activity 被销毁了,那么由于网络请求还没有返回,导致 Presenter 持有 Activity 对象,使得 Activity 无法被回收,此时就会发生内存泄露。(也许应用中出现一次两次内存泄漏不会造成多大的影响,但应用在长时间使用后,若这些占据系统的大量内存的 Activity 得不到 GC 回收的话,最终会导致 OOM 的出现,就会直接 Crash 应用。)
  • 解决办法:通过弱引用和 Activity、Fragment 的生命周期来绑定/解绑 View 解决这个问题,建立 BasePresenter,是一个泛型类 ,泛型类型为 View 角色要实现的接口类型 。
  • 好处:Presenter 不需要在构造函数中传入 View 对象,而是在 View 中自由地通过Presenter 的 attachView 方法和 detachView 方法绑定和解绑 View 对象,除了 attachViewdetachView,我们还可以另外声明 onResume 和 onStop 方法。

Model层的单独优化

前面讲了 View 和 Presenter 两个层次,而 Model 层比较特殊,相对比较独立的存在,帮上层拿数据,这是因为 MVP 模式的理念就是让业务逻辑相互独立。但如果每个网络请求也独立成单个 Model 的话,代码操作起来也会非常麻烦,比如:

  1. 无法对所有 Model 统一管理;
  2. 每个 Model 对外提供的获取数据方法不一样,上层请求数据没有规范;
  3. 代码冗余,重复性代码多;
  4. 对已存在的 Model 进行修改繁琐;

那么就需要对 Model 进行封装优化,使得 Model 层变成一个庞大且独立单一的模块,请求方式规范化,管理直观化:

  1. 数据请求能够单独编写和测试,无需配合上层界面测试;
  2. 统一以 DataModel 类作为数据请求层的入口,通过反射机制获取对应的 Model;
  3. 无缝切换不同的数据源(网络请求库、缓存、数据库);

MVP结构图

MVP模式详细结构图

示例代码

效果图

MVP效果图

参考文章

上一篇 下一篇

猜你喜欢

热点阅读