原文：Architectural Guidelines to follow for MVP pattern in Android
默认情况下，Android没有强制使用任何架构模式。尽管这使得框架在开发应用程序时更加强大，但同样的情况也会使您的代码在更复杂的应用程序场景中更加脆弱。
这是因为在一段时间内，应用程序开发涉及更复杂的生命周期和特性管理，这可能会在不以适当的方式处理时造成应用程序的混乱。这就是为什么开发人员依赖于不同的架构模式，比如MVC、MVP和MVVM，用于Android的应用开发。
就我开发应用程序的经验而言，我建议使用MVP架构模式来开发Android应用程序。有了这篇文章，我打算帮助我的开发人员在开发带有MVP架构的android应用程序时遵循一些指导原则。在讨论指导方针之前，让我们了解一下Android的MVP架构模式到底是什么，以及每个人在他们的项目中应该如何使用它。
MVP架构模式——回顾
MVP架构设计模式是相当著名的Android开发者设计模式。它允许您通过引入一个称为“演示者”的中介来将业务逻辑（模型）与视图逻辑（活动/片段）分离。
正如其名称所暗示的，模型-视图-演示者被划分为三个不同的层，其独立的层定义如下：
Model :如上所述的模型，模型是存储业务逻辑和应用程序数据的地方。在Android中，Model的角色通常由数据访问层，如数据库API或REST API来扮演。不仅仅是模型负责存储应用程序数据，它还包括负责生成、公开和获取数据的组件。一般来说，所有这些功能都是在后台运行的，因为它们可以阻塞UI线程。视图视图基本上是一个被动的接口和UI，它负责将用户的操作路由到演示者。
VIEW:在Android中，View可以是你的活动、片段或回收器视图适配器。一般来说，除了应用程序的pojo和实体之外，view对你的模型是不可见的。为了使用更简单的术语，View不会直接与Model通信。然而，他们与Presenter交流。
Presenter:Presenter是视图和模型之间的中介或中介，它负责所有必须处理应用程序中表示逻辑的事情的责任。一般来说，演示者负责查询您的Model，在响应用户的交互时更新View。它监视Model和对话，以便当特定View需要更新时，它们可以处理，何时不需要更新。
为什么在Android中使用MVP架构模式？
MVP是为数不多的几个遵循bob叔叔的清洁架构指南的架构模式之一。以下是一些让MVP成为Android的优秀架构模式的原因
1.使应用程序中的调试更轻松
MVP强制执行三层不同的抽象层，这使得调试应用程序变得更加容易。而且，由于业务逻辑与视图完全解耦，所以在开发应用程序时执行单元测试更容易。
2.更好分离问题
mvp将你的业务逻辑和持久性逻辑从你的活动和片段类中分离出来，从而更好地执行好的问题分离。
3.代码的复用性
在MVP中，代码可以更好地复用，因为你可以有多个presenter来控制你的view。这一点更重要，因为你绝对不希望依靠一个presenter来控制你的不同view。
在Android中有效实现MVP架构模式的指导方针
1.让你的view尽可能简单
如果你问任何一个新手Android开发者，他们会告诉你为什么测试Android对测试人员来说更痛苦。在Android中，开发应用程序的常见模式是在单个Activity/Fragment类中编写数千行代码。然而，当您的应用程序发展并变得更加复杂时，同样的实现往往会变得有问题。为了解决这个问题，你应该让你的View尽可能的简单。你的view越简单，测试你的Android用户界面就越好。
在MVP中，你可以使用Passive View模式实现同样的功能。通过实现这个模式，您将通过引入一个通过与View对话来响应用户行为的演示者，将View的行为减少到几乎最小的级别。
例如，让我们考虑你需要在你的应用中实现一个登录界面。用户将会填写他们的注册电子邮件和用户名来登录。在实现相同的过程中，您不需要在View中编写身份验证逻辑。相反，您将把它写在Presenter程序中，当用户成功登录时（比如型材屏幕），它将更新您的View。在这种情况下，您的View的作用是只接收电子邮件和密码的输入，并将其传递给Presenter，后者将更新View。
2.在Model中管理远程和本地数据源
您可以通过在Model中管理远程和本地数据源来提高应用程序的速度。
例如，让我们假设您需要开发一个离线的应用程序，它甚至在数据连接关闭时也会运行，实现相同的一个解决方案是通过获取数据和存储缓存，这样当用户在线时就可以查询它。
您可以通过创建三个不同的Model类来实现这一点，特别是以远程数据源、本地数据源和数据存储库的形式。
你的数据存储库类将包含与Presenter对话的逻辑。
本地数据存储类可以处理缓存的数据和本地存储，而远程数据源类则处理所有远程API调用和响应。
3.使用像Dagger2和RxJava这样的库来最小化代码冗余
我建议使用像Dagger2这样的依赖注入库，这将使您的Model和Presenter程序独立于您的View的生命周期。
使用Dagger可以通过在它们之间注入依赖关系来简化组件的行为。
此外，您应该使用像RxJava这样的库，它将简化您的代码库，同时处理繁重的繁重工作，例如多个用户交互（如单击、滑动等）和用于网络的背景数据。
4.使用适当的命名约定来分离职责
为您在代码库中使用的方法使用适当的命名约定。一般来说，您有两种不同的方法，例如您的Presenter中的动作和用户事件。动作是包含View将被更新的逻辑的方法。
例如：load（）或loadmore（）将告诉演示者在用户向下滚动应用程序时加载另一个页面。
也就是说，View将知道何时更新自己（比如通过与演示者交谈），当用户滚动到页面的末尾时，用户事件表示由用户触发的动作。
例如：只有当用户键入正确数量的字符，显示相关的搜索时，才可以调用querychanged（）方法。
简单地说，应该使用适当的命名约定，它适合于需要触发的动作，这意味着应该运行什么逻辑，以及什么时候应该运行它。
5.让你的Presenter独立于一个框架来提高可测试性
在Android中使用MVP的主要想法是在你的项目中执行适当的可测试性。为了实现相同的（改进的可测试性），您应该使您的演讲者独立于任何Android类。主要的想法是让Presenter被剥夺任何平台的依赖，这样您就可以使用Junit测试演示者了。
您应该避免使用来自共享资源的上下文对象，使其更独立于平台。Ivan sk瑞克写了一篇很好的文章，解释了如何让你的Presenter独立于android国家。
总结
Android的MVP架构模式保持了代码的简单性和可重用性，这反过来又促进了更高的可测试性。
通过坚持MVP架构的以上几点，你可以有效地实现它，并利用它的优势为Android开发更好的移动应用。