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

Android框架中使用了多种模式，例如:

广播接收器使用观察者模式 远程服务调用使用代理模式 视图和视图组使用复合模式 媒体框架使用立面模式

Android也使用ViewHolder设计模式。

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

ViewHolder设计模式使您能够访问每个列表项视图，而不需要进行查找，从而节省宝贵的处理器周期。具体来说，它避免了在ListView滚动期间频繁调用findViewById()，这将使其平滑。

以下Android类使用设计模式

1)视图持有者使用单例设计模式

2)意图使用工厂设计模式

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

4)广播接收端采用观察者设计模式

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

6)媒体框架使用Façade设计模式

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

我尝试使用模型-视图-控制器(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开发。