我知道有很多关于这个的问题，但是，我仍然很难理解Activity 类在 Android 上实现传统的模型-视图-控制器设计模式时应该扮演什么角色？
我的直觉是它应该是控制器，但这意味着 UI 屏幕（因为每个屏幕必须有一个 Activity）和控制器之间存在一对一的关系，这违背了 MVC 松散耦合的观点不同组件之间。
【问题讨论】：
你是对的。 xml 接口可以定义为 View，而您使用数据的其他类可以定义为 Model。
Activity 接收来自 View 的所有事件和用户输入，因此，我们可以简单地说它是 Controller。
但是让我们明确一点，它不是一个完美的（它真的存在吗？）MVC
看看this question，更具体地说，接受答案的第一条评论，它可能有用
【讨论】：
Activity 可以成为称职的控制器，并且通过片段，您还可以实现分层 MVC。 MVC 的大部分工作取决于程序员，因为即使在最严格的框架中，您仍然可以找到do crazy things 的方法。
【讨论】：
Android 没有良好的架构，也没有遵循 MVC 设计模式。
在 MVC 中将 Activity 概念化的最佳方式是作为视图（带有一些控制器逻辑），因为每次发生配置更改（例如屏幕旋转或区域设置更改）时，它都会被销毁，从而丢失其所有状态。
在这种情况下，控制器将是 Application 对象，因为它是您从 Activity 上下文之外的代码访问视图（Activity 及其 GUI 组件）的桥梁。您必须使用单例，以便在给定时间只有一个 Application 对象，否则每个进程将有一个 Application 对象。 Application 对象不是存储模型的好地方，因为它的生命周期与活动的生命周期是分离的。它可以在 Activity 生命周期的任何时候被销毁和重新创建（当应用程序在后台时），而不会导致它重新启动，然后它的所有变量和未在其 onCreate() 方法中分配的引用都将变为 null。
因此，模型必须存储在带有 setRetainInstance(true) 的无 GUI、无头片段上，该片段链接到活动，并且每次重新创建活动时都必须重新附加到它。您必须使用片段管理器来确保您正在恢复保留的片段而不是重新创建它。这也是运行后台任务的最佳位置，尽管您也可以在 Application 对象中运行它们。永远不要在 Activity 上运行任务，因为它们会在配置更改时被销毁。
【讨论】：
我认为将视图定义为 XML 可能会引起混淆，因此 Activity 被误认为是视图。它不是。您将视图（您的 XML 布局）传递到 Activity 中，该 Activity 将扩展 XML 布局中包含的视图。您的活动还将数据（模型）传递到您的视图（EditText、TextView、基本视图的扩展版本等）。
如果你真的想要 MVC，那么你可以简单地通过在 XML 布局中设置你的视图来实现这一点，创建一个从你的根视图扩展的视图对象（如果它是从那扩展的 RelativeLayout）。从那里您可以添加访问器方法和该视图所需的不同逻辑，然后您可以围绕它添加单元测试。
在 Activity 中，您将不再传递布局的 ID，而是执行以下操作：
CustomView customView = new CustomView(...);
setContentView(customView);
...
当然，几乎所有应用程序都不会这样做，您也确实不需要这样做。调用 findViewById 就足以链接到该视图对象并调用它拥有的方法。在我看来，这就是 MVC。
【讨论】：