我看到很多人说MVC已经在Android中实现了，但这不是真的。Android默认不遵循MVC。

因为我不谷歌将永远强制MVC实现像iPhone的限制，但它取决于开发人员的模式或技术，他们想在他们的项目，在小或简单的应用程序使用MVC是不需要的，但随着应用程序的增长，变得复杂，并需要修改其代码在以后的几年，然后有一个MVC模式在Android的需求。

它提供了一种修改代码的简单方法，还有助于减少问题。 如果你想在Android上实现MVC，那么按照下面给出的链接，在你的项目中享受MVC实现。

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

但是现在，我认为MVP和Android架构模式是开发人员应该使用的干净和健壮的Android应用程序的最佳选择之一。

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

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

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

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

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

我认为最有用的简单解释是: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

从我在这里看到和读到的所有东西来看，实现所有这些东西都变得更加困难，并且与android的其他部分不太适应。

让一个活动实现其他监听器已经是标准的Android方式。最无害的方法是像幻灯片所描述的那样添加Java观察者，并将onClick和其他类型的操作分组到仍然在Activity中的函数中。

Android的方式是Activity两者都做。与之斗争并不能真正使扩展或将来的编码变得更容易。

我同意第二篇文章。它已经实现了，只是不是人们习惯的方式。不管它是否在同一个文件中，已经有分离了。不需要创建额外的分隔来适应其他语言和操作系统。

经过一番搜索，最合理的答案是:

MVC已经在Android中实现了:

View =布局，资源和内置类，如从android.view.View派生的Button。 控制器=活动 模型=实现应用程序逻辑的类

(顺便说一下，这意味着活动中没有应用程序域逻辑。)

对于小型开发人员来说，最合理的做法是遵循这种模式，不要尝试做谷歌决定不做的事情。

PS注意，活动有时会重新启动，所以它不是模型数据的地方(引起重新启动的最简单的方法是从XML中省略android:configChanges="keyboardHidden|orientation"，然后转动你的设备)。

EDIT

我们可能会谈论MVC，但它会这样说，FMVC，框架-模型-视图-控制器。框架(Android操作系统)强加了它的组件生命周期和相关事件的想法，在实践中，控制器(活动/服务/BroadcastReceiver)首先负责处理这些框架强加的事件(如onCreate())。是否应该单独处理用户输入?即使应该，你也不能把它分开，用户输入事件也来自Android。

总之，你在Activity/Service/BroadcastReceiver中植入的非android专用代码越少越好。

根据Xamarin团队的解释(在iOS MVC中“我知道这看起来很奇怪，但等一下”):

模型(数据或应用程序逻辑)， 视图(用户界面)和 控制器(后面的代码)。

我可以这样说:

Android上的模型只是一个可打包对象。视图是XML布局，控制器是(活动+它的片段)。

*这只是我个人的观点，不是来自任何资源或书籍。