我尝试同时使用模型-视图-控制器（MVC）和model–view–preserver进行android开发的架构模式。我的发现是model–view-controller工作正常，但有几个“问题”。这一切都归结为你如何看待androidActivity类。它是控制器还是视图？

实际的Activity类没有扩展Android的View类别，但它确实处理向用户显示窗口以及该窗口的事件（onCreate、onPause等）。

这意味着，当您使用MVC模式时，您的控制器实际上将是一个伪视图-控制器。由于它处理向用户显示窗口，以及您通过setContentView添加到其中的其他视图组件，并且还处理至少各种活动生命周期事件的事件。

在MVC中，控制器被认为是主要的入口点。如果将其应用于Android开发时是这样的话，这就有点争议了，因为该活动是大多数应用程序的自然切入点。

正因为如此，我个人发现模型-视图-演示模式非常适合Android开发。由于视图在此模式中的作用是：

• Serving as a entry point
• Rendering components
• Routing user events to the presenter

这允许您实现您的模型，如下所示：

视图-它包含您的UI组件，并为它们处理事件。

演示者-这将处理模型和视图之间的通信，将其视为通往模型的网关。这意味着，如果你有一个复杂的领域模型来表示，天知道吗，而你的视图只需要这个模型的一小部分，演示者的工作就是查询模型，然后更新视图。例如，如果您有一个模型，其中包含一段文本、一个标题和一个字数。但在给定的视图中，您只需要在视图中显示标题。然后演示者将从模型中读取所需的数据，并相应地更新视图。

模型-这基本上应该是您的全域模型。希望这将有助于使您的领域模型更加“紧凑”，因为您不需要特殊的方法来处理上述情况。

通过将模型与视图解耦（通过使用演示者），测试模型也变得更加直观。您可以对域模型进行单元测试，也可以对演示者进行单元测试。

试试看。我个人认为它非常适合安卓系统的开发。

2018年11月更新

在安卓系统中写了几年关于MVC和MVP的博客（见下面的答案）后，我决定以一种更全面、更容易理解的形式获取我的知识和理解。

因此，我发布了一个关于Android应用程序架构的完整视频课程。因此，如果您有兴趣掌握Android开发中最先进的体系结构模式，在此处查看此综合课程。

此答案已更新，以便自2016年11月起保持相关性

看起来您正在寻找体系结构模式而不是设计模式。

设计模式旨在描述程序员为处理一组特定的重复软件任务而可能实现的一般“技巧”。例如：在OOP中，当一个对象需要向一组其他对象通知某些事件时，可以采用观察器设计模式。

由于Android应用程序（以及大多数AOSP）是用面向对象的Java编写的，我认为你很难找到一个Android上没有使用的单一OOP设计模式。

另一方面，体系结构模式并不涉及特定的软件任务，它们旨在根据相关软件组件的用例为软件组织提供模板。

这听起来有点复杂，但我希望一个例子能澄清：如果某个应用程序将用于从远程服务器获取数据，并以结构化的方式将其呈现给用户，那么MVC可能是一个很好的考虑对象。请注意，我没有提到应用程序的软件任务和程序流——我只是从用户的角度描述了它，出现了一个架构模式的候选。

既然你在问题中提到了MVC，我想架构模式就是你想要的。

从历史上看，谷歌没有关于应用程序架构的官方指导方针，这（以及其他原因）导致了安卓应用程序源代码的混乱。事实上，即使在今天，我看到的大多数应用程序仍然没有遵循OOP最佳实践，也没有显示出清晰的代码逻辑组织。

但今天的情况不同了——谷歌最近发布了数据绑定库，它与Android Studio完全集成，甚至推出了一套Android应用程序的架构蓝图。

两年前，在Android上很难找到有关MVC或MVP的信息。如今，MVC、MVP和MVVM已经成为安卓社区的“流行语”，我们周围有无数专家，他们不断试图说服我们MVx比MVy更好。在我看来，讨论MVx是否比MVy更好是完全没有意义的，因为术语本身非常模糊——看看这个问题，你会意识到不同的人可以将这些缩写与完全不同的结构联系起来。

由于Android最佳架构模式的搜索已经正式开始，我认为我们即将看到更多的想法浮出水面。在这一点上，我们真的无法预测未来哪种模式会成为行业标准——我们需要拭目以待（我想这是一两年的问题）。

然而，我可以满怀信心地做出一个预测：数据绑定库的使用不会成为行业标准。我很有信心地说，因为数据绑定库（在其当前实现中）提供了短期的生产力提高和某种架构指导，但从长远来看，它将使代码不可维护。一旦这个图书馆的长期影响浮出水面，它就会被抛弃。

现在，尽管我们今天确实有一些官方指南和工具，但我个人并不认为这些指南和工具是最好的选择（而且它们绝对不是唯一的）。在我的应用程序中，我使用自己的MVC体系结构实现。它简单、干净、可读、可测试，并且不需要任何额外的库。

这种MVC不仅在外观上与其他MVC不同，它还基于一种理论http://www.techyourchance.com/activities-android/“rel=”nofollow noreferrer“>Android中的活动不是UI元素，这对代码组织有着巨大的影响。

因此，如果您正在为Android应用程序寻找一个良好的体系结构模式，请遵循SOLID原则，你可以在我关于Android中的MVC和MVP架构模式。

当我读到这篇文章时，它真的帮助我通过例子来理解模式，所以我制作了下表，以清楚地看到设计模式&；他们在安卓框架中的例子

我希望你会觉得它有帮助。

• 一些有用的参考链接：
  

  1. Common Design Patterns for Android with Kotlin

  2. Android设计模式简介

  3. 设计模式

Android框架中使用了各种模式，如：

• Broadcast receiver uses Observer pattern
• Remoter service invocation uses Proxy pattern
• View and view group uses Composite pattern
• Media framework uses Facade pattern

这是一篇关于Android常见设计模式：

创作模式：

• Builder (e.g. AlertDialog.Builder)
• Dependency Injection (e.g. Dagger 2)
• Singleton

结构模式：

• Adapter (e.g. RecyclerView.Adapter)
• Facade (e.g. Retrofit)

行为模式：

• Command (e.g. EventBus)
• Observer (e.g. RxAndroid)
• Model View Controller
• Model View ViewModel (similar to the MVC pattern above)

以下Android类使用设计模式

1） View Holder使用Singleton设计模式

2） 意向使用工厂设计模式

3） 适配器使用适配器设计模式

4） 广播接收机采用观测器设计模式

5） 视图使用组合设计模式

6） 媒体框架采用立面设计模式

在Notifications情况下，NotificationCompat.Builder使用Builder模式

喜欢

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

安卓系统也使用ViewHolder设计模式。

它用于在滚动ListView时提高它的性能。

ViewHolder设计模式使您无需查找即可访问每个列表项视图，从而节省宝贵的处理器周期。特别是，它避免了在ListView滚动过程中频繁调用findViewById（），这将使它变得平滑。

所有这些模式，MVC，MVVM、MVP和演示模型，可以应用于Android应用程序，但如果没有第三方框架，就不容易获得组织良好的结构和干净的代码。

MVVM源自PresentationModel。当我们应用MVC时，MVVM和演示模型对于Android应用程序，我们真正想要的是有一个清晰的结构化项目，更重要的是更容易进行单元测试。

目前，如果没有第三方框架，通常会有很多代码（如addXXListener（）、findViewById（）等），这些代码不会增加任何业务价值。更重要的是，你必须运行Android单元测试，而不是普通的JUnit测试，这需要很长时间才能运行，并且使得单元测试有些不切实际。

出于这些原因，几年前我们启动了一个开源项目，RoboBinding-Android平台的数据绑定演示模型框架。RoboBinding帮助您编写更易于阅读、测试和维护的UI代码。RoboBinding消除了不必要的代码（如addXXListener等）的需要，并将UI逻辑转移到演示模型，即POJO，可以通过常规JUnit测试进行测试。RoboBinding本身提供了300多个JUnit测试，以确保其质量。