问题：真的很大且复杂的Activity类。难以阅读/理解和修改。很难测试。
可能的解决方案：Model-View-Presenter（可能带有依赖注入）。 和模拟测试对象！
我打算在我的Android应用程序中实现Model-View-Presenter。 这基本上是模型 - 视图 - 控制器的变体。从本质上讲，制作活动 一个美化的布局管理器，并将任何业务逻辑推迟到Presenter。另一种查看Presenter的方法是，它就像一个在Activity中实例化的Helper类，通过提供Presenter可以使用的接口/回调的活动来完成繁重的工作。
我想得到一些社区的想法。例如：
这暗示了什么接口？
模型和视图对演示者有什么责任。
对于Presenter，我想Activity会实现Presenter所需的接口？
Presenter与Activity之间应该包含哪些内容？
演示者是否与活动一对一？那么一个Activity有多个片段显示不同的小部件，每个小部件都有自己的适配器？我们现在需要多个演示者还是只有一个？
Presenter与适配器怎么样？
演示者应如何与ListView和ListViewAdapter说出一个Activity？
什么进入Presenter与适配器？
Presenter应该选择要使用的适配器吗？或者活动应该做出这个决定？
Presenter应该处理模型数据还是适配器？适配器和演示者之间是否存在冲突？适配器是主持人吗？或更少/更多的东西。通常，适配器仅适用于活动中的ListViews等小部件。我认为他们不会调用获取数据本身。
因此，在模型 - 视图 - 演示者中，关键是要确定演示者与其他类的内容以及演示者与活动，适配器和视图/包括片段之间的通信。
Model-View-Presenter对Android来说真是个糟糕的主意吗？或者它是否适合Android框架？
请记住，Android之外有很多非常成熟的SDK仍然需要像MVP这样的微架构。事实上，例子比比皆是：例如。 Flex是非常成熟的Flash SDK，但它仍然需要几乎所有主要应用程序的MVP和MVC框架。
EJB需要Spring来简化和组织它。 MFC / Struts等和列表一直在继续。为什么Android会有所不同？为什么我们应该假设SDK在没有像MVP这样的设计模式的情况下具有Android所需的一切？
在我花费数百小时的时间之前很高兴知道，请随时评论/回答此问题的任何部分。
答案 0 :(得分：3)
Android比我遇到过的任何平台都更能惩罚糟糕的MV（P | C）设计。忘记它为在活动堆栈中上下传递状态提供的笨拙方法。从您的活动中获取尽可能多的状态和逻辑。根据需要将其移动到Services，ContentProviders和SharedPreferences中。尝试使您的活动纯粹的视图。 IMO，服务在Android教程中从未得到足够的重视。即使是O＆＃39; Reilly 编程Android 书也只给他们四分之一页！
警惕扩展应用程序。如果您在自己的进程中启动了一个服务（例如，当一个Activity崩溃时允许它正常关闭），那么该服务将拥有自己的应用程序副本。
答案 1 :(得分：2)
只是为可能感兴趣的其他人提供参考。几年前我在思考同样的事情。当我们将MVC / MVVM / Presentation Model应用于Android应用程序时，我们真正想要的是拥有一个清晰的结构化项目，更重要的是更容易进行单元测试。目前，没有第三方框架，您通常会有很多代码（如addXXListener（），findViewById（）...），它不会添加任何业务价值。更重要的是，你必须运行android单元测试而不是正常的JUnit测试，这需要花费很长时间才能运行并使单元测试有些不切实际。出于这些原因，几年前我们开始了一个开源项目RoboBinding - 一个用于Android平台的数据绑定表示模型框架。 RoboBinding可帮助您编写易于阅读，测试和维护的UI代码。 RoboBinding不需要不必要的代码，如addXXListener等，并将UI逻辑转换为Presentation Model，这是一个pojo，可以通过正常的JUnit测试进行测试。 RoboBinding本身带有300多个JUnit测试，以确保其质量。其他选择：Android-Binding，Bindroid和MvvmCross。