没有一个单一的MVC模式可以遵循。MVC只是或多或少地说明了你不应该将数据和视图混为一谈，例如，视图负责保存数据，或者处理数据的类直接影响视图。

但无论如何，Android处理类和资源的方式，有时你甚至被迫遵循MVC模式。在我看来，更复杂的是那些有时负责视图，但同时又充当控制器的活动。

如果您在XML文件中定义视图和布局，从res文件夹加载资源，并且如果您或多或少地避免在代码中混合这些东西，那么您无论如何都是在遵循MVC模式。

我发现在Android上实现MVC最好的资源是这篇文章:

我在自己的一个项目中采用了同样的设计，效果非常好。我是Android的初学者，所以我不能说这是最好的解决方案。

我做了一个修改:我实例化了应用程序类中每个活动的模型和控制器，这样当横向-纵向模式更改时就不会重新创建这些模型和控制器。

当我们将MVC、MVVM或Presentation Model应用到Android应用中时，我们真正想要的是有一个清晰的结构化项目，更重要的是更容易进行单元测试。

目前，如果没有第三方框架，通常会有大量代码(如addXXListener()、findViewById()等)，这不会增加任何业务价值。

更重要的是，你必须运行Android单元测试，而不是正常的JUnit测试，后者需要很长时间才能运行，并且使单元测试有些不切实际。基于这些原因，几年前我们开始了一个开源项目RoboBinding——一个用于Android平台的数据绑定表示模型框架。

RoboBinding帮助您编写更易于阅读、测试和维护的UI代码。RoboBinding消除了对addXXListener等不必要代码的需求，并将UI逻辑转移到表示模型(Presentation Model)，这是一个POJO，可以通过正常的JUnit测试进行测试。RoboBinding本身带有300多个JUnit测试，以确保其质量。

在我看来，Android处理MVC模式的方式是这样的:

您有一个充当控制器的Activity。你有一个负责获取数据的类，即模型，然后你有一个View类，即视图。

当谈到视图时，大多数人只想到xml中定义的可视部分。不要忘记，视图也有一个程序部分，它的构造函数，方法等，在java类中定义。

Android上的动作、视图和活动是与Android UI一起工作的内置方式，是模型-视图-视图模型(MVVM)模式的实现，它在结构上与模型-视图-控制器相似(在同一家族中)。

据我所知，没有办法打破这个模式。这可能是可以做到的，但是您可能会失去现有模型的所有好处，并且必须重写自己的UI层以使其正常工作。

我同意JDPeckham的观点，并且我相信XML本身不足以实现应用程序的UI部分。

然而，如果你认为Activity是视图的一部分，那么实现MVC是相当简单的。您可以重写Application(由Activity中的getApplication()返回)，在这里您可以创建一个在应用程序的生命周期中存在的控制器。

(或者，您也可以使用应用程序文档中建议的单例模式)