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

我想添加一个设计模式，已经应用在Android框架。这是在Asynctask实现中使用的半同步半异步模式。请参阅我在

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

所有这些模式，MVC, MVVM, MVP和Presentation Model，都可以应用到Android应用中，但是如果没有第三方框架，就不容易得到组织良好的结构和干净的代码。

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

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

基于这些原因，几年前我们开始了一个开源项目RoboBinding——一个用于Android平台的数据绑定表示模型框架。RoboBinding帮助您编写更易于阅读、测试和维护的UI代码。RoboBinding消除了对addXXListener等不必要代码的需求，并将UI逻辑转移到表示模型(Presentation Model)，这是一个POJO，可以通过正常的JUnit测试进行测试。RoboBinding本身带有300多个JUnit测试，以确保其质量。

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通用设计模式的文章:

创建型模式:

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

结构模式:

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

行为模式:

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

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