我正在对移动平台做一个小的研究，我想知道Android中使用了哪些设计模式？

例如，在iOS模型中，视图控制器与委托和其他模式一起被广泛使用。

Android使用什么模式，特别是在哪里？

编辑

我并不是要求在内核、dalvik等内部使用设计模式，而是要求应用程序开发人员在开发应用程序时遇到的模式。

我尝试使用Model–View–Controller(MVC)和Model–View–Presenter设计模式进行Android开发。我的发现是模型-视图-控制器工作正常，但有几个"问题"。这一切都取决于你如何看待android Activity类。它是控制器还是视图？

实际的Activity类并没有扩展android的View类，但是它可以处理向用户显示窗口，也可以处理该窗口的事件(oncreate、onpause等)。

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

在MVC中，控制器应该是主要的入口点。如果把它应用到Android开发中，这是有点争议的，因为活动是大多数应用程序的自然入口点。

因此，我个人发现模型-视图-演示者模式非常适合Android开发。因为视图在此模式中的角色是：

• 作为入口点
• 渲染组件
• 将用户事件路由到演示者

这允许您像这样实现您的模型：

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

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

模型-这基本上应该是您的完整域模型。希望它也能帮助您的域模型变得更"紧"，因为您不需要特殊的方法来处理上面提到的情况。

通过将模型与视图完全分离(通过使用演示者)，测试模型也变得更加直观。您可以为域模型进行单元测试，也可以为演示者进行单元测试。

试试看。我个人认为它非常适合Android开发。

更新日期：2018年11月好的。

在Android平台上写了几年关于MVC和MVP的博客(见下面答案的正文)，我决定以一种更全面、更容易理解的形式来获取我的知识和理解。好的。

所以，我发布了一个关于Android应用程序体系结构的完整视频课程。因此，如果您对掌握Android开发中最先进的体系结构模式感兴趣，请阅读下面的综合课程。好的。

为了在2016年11月保持相关性，更新了此答案。好的。

看起来您是在寻找架构模式，而不是设计模式。好的。

设计模式的目的是描述一个一般的"技巧"，程序员可以实现这个技巧来处理一组特定的循环软件任务。例如：在OOP中，当需要一个对象通知一组其他对象有关某些事件时，可以使用观察者设计模式。好的。

由于Android应用程序(和大多数的AOSP)都是用Java编写的，这是面向对象的，所以我认为很难找到一个不在Android上使用的单一OOP设计模式。好的。

另一方面，体系结构模式并不能解决特定的软件任务——它们旨在根据所讨论的软件组件的用例为软件组织提供模板。好的。

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

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

好的。

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

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

两年前，在Android上很难找到有关MVC或MVP的信息。今天，MVC、MVP和MVVM已经成为安卓社区的"热门词汇"，我们身边有无数的专家，他们不断地试图说服我们，MVX比MVY更好。在我看来，讨论mvx是否比mvy更好是毫无意义的，因为术语本身是非常模糊的-只要看看这个问题的答案，你就会发现不同的人可以将这些缩写与完全不同的结构联系起来。好的。

由于对Android最佳架构模式的搜索已经正式开始，我想我们将看到更多的想法。在这一点上，很难预测哪种模式(或模式)将来会成为行业标准——我们需要拭目以待(我猜这是一两年的事情)。好的。

但是，我可以高度自信地做出一个预测：数据绑定库的使用不会成为行业标准。我有信心这么说，因为数据绑定库(在当前的实现中)提供了短期的生产力提升和某种体系结构指导，但从长远来看，它将使代码不可维护。一旦这个图书馆的长期影响浮出水面，它将被废弃。好的。

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

这个MVC不仅在外观上不同于其他的MVC——它基于一种理论，即Android中的活动不是UI元素，这对代码组织有着巨大的影响。好的。

所以，如果你想为Android应用程序寻找一个遵循可靠原则的良好架构模式，你可以在我的文章中找到一个关于Android中MVC和MVP架构模式的描述。好的。好啊。

当我到这后它真的帮助我了解到我有一个模式与下面的例子清楚地看到"表设计模式例子&；他们在Android框架

我希望你会发现它helpful。

• 一些有用的链接，供参考：

• 常见的设计模式与kotlin Android

• Android系统设计模式导论

• 设计模式

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

• 广播接收机采用观测器模式
• 远程服务调用使用代理模式
• 视图和视图组使用复合模式
• 媒体框架使用外观模式

这里是一个伟大的文章：通用设计模式是Android在线

creational模式：

• 生成器(如alertdialog.builder)
• 依赖注入(如匕首2)
• 单身

结构类型：

• 适配器(例如recyclerview.adapter)
• (例如，改造门面)

行为模式：

• 命令(例如，eventbus)
• 观察(例如rxandroid)
• 模型视图控制器
• 模型视图，视图模型(类似于上述的MVC模式)

Android使用下面的类设计模式

1)使用Singleton设计模式的视图。

2)使用工厂设计模式。

3)适配器使用适配器的设计模式

4)广播接收器使用Observer设计模式

5)使用设计模式复合视图

6)框架使用的媒体的发？ade设计模式

在案件的通知，NotificationCompat.Builder使用生成器模式

样，

viewholder Android也使用设计模式。

它是用来改善性能而在ListView的滚动它。

设计模式，使你的viewholder访问每个列表视图的项目不需要查找，节约宝贵的处理器周期。具体而言，它avoids频繁调用的过程()(findviewbyid ListView的滚动，那将使它光滑。

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

从presentationmodel MVVM是一台。当我们应用MVC模型和MVVM，呈现一个Android应用程序，我们真正想要的，是有一个清晰的和更重要的是结构化的项目更容易被单元测试。

目前，没有一个第三方框架，你通常有很多的代码(如addxxlistener()，()，()，findviewbyid等)，而不添加任何商业价值。什么是更多，你必须运行于Android的单元测试JUnit测试可以正常运行，这将使你impractical单元测试点。

为这些原因，一些年前，我们的开源项目的开始日期，robobinding -结合演示模型架构的Android平台。帮助你写robobinding UI代码是更容易阅读，测试，和维护。robobinding removes需要不必要的代码或操作系统(像addxxlistener UI逻辑，和位移的表示模型，这是一个POJO和JUnit测试可以通过测试正常。超过300 robobinding本身是孤立的JUnit测试，以确保其质量。

我想添加一个已经在Android框架中应用的设计模式。这是AsyncTask实现中使用的半同步半异步模式。查看我的讨论

https://docs.google.com/document/d/1 ou zihwxawgtadjc013-boluhpmrjeubzndupkzmxeej0/编辑？USP =共享

在Android的"工作队列处理器卸载到"模式是常用的任务，从应用程序的主线程。

示例：《intentservice类的设计。

在接收到的intentservice在特定的政策目标，启动和停止线程，服务请求的处理是适当的。所有的在线单线程。

"观察者模式"，使用的粘结剂是死亡的收件人的通知。