这是一篇关于Android通用设计模式的文章:

创建型模式:

构建器(例如AlertDialog.Builder) 依赖注入(如匕首2) 单例

结构模式:

适配器(例如RecyclerView.Adapter) 外观(如翻新)

行为模式:

命令(例如EventBus) 观察者(例如RxAndroid) 模型视图控制器 (类似于上面的MVC模式)

在Notifications情况下，NotificationCompat。构建器使用构建器模式

就像,

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);

2018年11月更新

在关于Android中的MVC和MVP的工作和博客上写了几年之后(见下面的答案正文)，我决定以一种更全面、更容易理解的形式来捕捉我的知识和理解。

所以，我发布了一个完整的关于Android应用程序架构的视频课程。所以，如果你对掌握Android开发中最先进的架构模式感兴趣，请在这里查看这门综合课程。

为了保持2016年11月的相关性，我们更新了这个答案

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

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

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

另一方面，体系结构模式不处理特定的软件任务——它们旨在基于所讨论的软件组件的用例为软件组织提供模板。

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

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

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

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

Two years ago it was very hard to find information about MVC or MVP on Android. Today, MVC, MVP and MVVM has become "buzz-words" in the Android community, and we are surrounded by countless experts which constantly try to convince us that MVx is better than MVy. In my opinion, discussing whether MVx is better than MVy is totally pointless because the terms themselves are very ambiguous - just look at the answers to this question, and you'll realize that different people can associate these abbreviations with completely different constructs.

由于对Android最佳架构模式的搜索已经正式开始，我想我们将会看到更多的想法浮出水面。在这一点上，真的不可能预测哪种(或哪种)模式将在未来成为行业标准——我们需要等待和观察(我猜这是一两年的问题)。

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

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

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

所以，如果你正在为遵循SOLID原则的Android应用程序寻找一个好的架构模式，你可以在我关于Android中的MVC和MVP架构模式的帖子中找到一个描述。

在Android中，“工作队列处理器”模式通常用于从应用程序主线程中卸载任务。

示例:IntentService类的设计。

IntentService接收intent，启动工作线程，并适当地停止服务。所有请求都在一个工作线程上处理。

我尝试使用模型-视图-控制器(MVC)和模型-视图-呈现者架构模式来进行android开发。我的发现是模型-视图-控制器工作得很好，但有几个“问题”。这一切都取决于你如何看待Android Activity类。它是控制器还是视图?

实际的Activity类并没有扩展Android的View类，但是它可以处理向用户显示一个窗口，也可以处理该窗口的事件(onCreate, onPause等)。

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

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

正因为如此，我个人认为模型-视图-呈现者模式非常适合Android开发。因为视图在这个模式中的角色是:

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

这允许你像这样实现你的模型:

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

Presenter - this will handle communication between your model and your view, look at it as a gateway to your model. Meaning, if you have a complex domain model representing, God knows what, and your view only needs a very small subset of this model, the presenters job is to query the model and then update the view. For example, if you have a model containing a paragraph of text, a headline and a word-count. But in a given view, you only need to display the headline in the view. Then the presenter will read the data needed from the model, and update the view accordingly.

模型——这应该是你的全域模型。希望它也能帮助您使域模型更加“紧凑”，因为您不需要像上面提到的那样使用特殊的方法来处理情况。

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

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

Binder对死亡接收人通知使用“观察者模式”。