Android MVP解释

Question

我试着理解什么是最好的方法是编写一个“干净”的Android应用程序。我发现了一个有趣的文章，在那里他们使用了一种3层体系结构。

现在我读到android使用MVP设计模式，并试图理解这一点。我理解MVP原则的方式(在android环境中)是：

• 模型层是逻辑类
• 演示者是与XML (活动)“链接”的类。
• 被动视图是XML的。

是对的吗？

如果这是正确的，那么是否也修正了，即3层模型完全符合MVP原则，因为：

1. 3层体系结构的表示层适用于MVP的演示器层。
2. 3层体系结构中的业务层和数据层非常适合MVP的模型部分？

我希望我的问题是清楚的，因为这对我来说是一个复杂的话题。

也许这能澄清我对这件事的看法.

​

Answer 1

我首先要澄清的是，MVP或任何其他模式都不是Android的具体内容，可以应用于任何其他框架。

我想你明白其中的要点了：

• 视图通常由活动和片段实现，并将包含对演示者的引用。
• 演示者是介于视图和模型之间的中间人物。从模型中检索数据并返回已经格式化为视图的数据，因此它不需要做任何其他事情，只需要显示它。
• 该模型可以被简单地看作是“数据提供者”。它可以像你想的那样复杂，使用内部数据库，很多类等等。

如果您对Android应用程序体系结构感兴趣，我建议您观看今年Android峰会上的演讲。这是我见过的强项之一

https://www.youtube.com/watch?v=BlkJzgjzL0c

Answer 2

即使这个问题有答案，我也不认为这个答案是完全的。

MVP是一个通用的概念，可以有许多不同的实现，其中一些有很大的不同。而且，这个概念本身是非常模糊的--不同的人在说MVP时会有不同的概念。下面的图片显示了最普遍的情况之一：

​

​

无论实现如何，MVP组件的一般定义是：

• 模型：“应用程序状态存储”的抽象。“状态”是什么以及如何存储的定义是实现细节。模型实现不应依赖于视图或演示程序。
• 视图：“用户界面”的抽象。“用户”的定义及其与视图的交互方式是实现细节。视图实现不应依赖于模型或演示程序。
• 演示者:封装应用程序的业务逻辑。演示者处理从视图接收的用户输入事件，并根据响应更改存储在模型中的应用程序的状态。演示者还处理存储在模型中的应用程序状态的更改，并响应更新视图。演示者通常同时依赖于视图和模型。

如果您需要有关Android开发上下文中MVP的更多信息，您可以在下面的文章中找到：Android中的MVP和MVC体系结构模式。

Answer 3

在android中实现MVP时需要解决的重要问题是活动泄漏，由于后台进程更新关闭的活动而导致内存泄漏和应用程序崩溃。

由于演示者引用活动，如果不能垃圾收集演示者，活动将留在内存中。

这两个问题都可以通过使用活动或片段的生命周期方法来解决，并在这些方法中释放资源，从而防止内存泄漏和应用程序崩溃。

使用RXJava可以轻松地完成与资源相关的后台工作，有关MVP和MVP使用RXJava的更多信息，请参见http://www.zoftino.com/android-model-view-presenter-mvp-pattern-example。