Android上使用哪种devise模式？
我正在做一个移动平台的小型研究，我想知道哪些devise模式在Android中使用？
例如在iOS Model-view-controller中，与代理和其他模式一起使用非常广泛。
Android使用哪些模式和特定的位置？
编辑
我并不是要求在内核，dalvik等深入使用的devise模式，而是要求应用程序开发人员在开发应用程序时会遇到的模式。
我尝试使用模型视图控制器 （MVC）和模型视图演示者devise模式进行Android开发。 我的发现是模型视图控制器工作正常，但有几个“问题”。 这一切都归结于你如何看待Android Activity类。 它是一个控制器，还是一个视图？
实际的Activity类不会扩展Android的View类，但是它会处理向用户显示一个窗口，并处理该窗口的事件（onCreate，onPause等）。
这意味着，当您使用MVC模式时，您的控制器实际上将是一个伪视图控制器。 由于它正在处理向用户显示一个窗口，其中已经使用setContentView添加了其他视图组件，并且还处理至less各种活动生命周期事件的事件。
在MVC中，控制器应该是主要的入口点。 如果将其应用到Android开发中，这是有点争议的，因为活动是大多数应用程序的自然切入点。
正因为如此，我个人发现， 模型 – 视图 – 演示者模式是一个完美契合Android的发展。 由于这个模式中的angular色是：
- 作为切入点
- 渲染组件
- 将用户事件路由到演示者
这允许你像这样实现你的模型：
查看 – 这包含你的用户界面组件，并为他们处理事件。
演示者 – 这将处理您的模型和视图之间的通信，将其视为您模型的入口。 意思是说，如果你有一个复杂的领域模型代表，神知道什么，你的观点只需要这个模型的一个非常小的子集，主持人的工作是查询模型，然后更新视图。 例如，如果您的模型包含一段文字，一个标题和一个字数。 但是在给定的视图中，您只需要在视图中显示标题。 然后，演示者将读取模型中需要的数据，并相应地更新视图。
模型 – 这应该基本上是你的完整领域模型。 希望这将有助于使你的领域模型更“紧”，因为你不需要特殊的方法来处理上面提到的情况。
通过将模型从视图中解耦出来（通过使用演示者），testing模型也变得更加直观。 您可以为您的域模型进行unit testing，并为您的演示者进行unit testing。
试试看。 我个人觉得它非常适合Android开发。
此答案已更新，以便于2016年11月保持相关
看起来你正在寻找build筑模式而不是devise模式 。
devise模式旨在描述程序员可能实现的处理一组特定软件任务的一般“技巧”。 例如：在OOP中，当需要一个对象通知一组其他对象时，可以使用观察者devise模式 。
由于Android应用程序（以及大多数AOSP）都是用面向对象的Java语言编写的，所以我认为您将很难find一个不适用于Android的OOPdevise模式。
另一方面， 架构模式并不涉及特定的软件任务 – 它们旨在基于所讨论的软件组件的使用情况为软件组织提供模板 。
这听起来有些复杂，但是我希望有一个例子可以澄清：如果某个应用程序将用于从远程服务器获取数据并以结构化方式呈现给用户，那么MVC可能是一个值得考虑的候选项。 请注意，我没有提到应用程序的软件任务和程序stream程 – 我只是从用户的angular度来描述它，并且出现了架构模式的候选人。
既然你在提到的问题中提到了MVC，那么我猜想架构模式就是你正在寻找的东西。
从历史上看，Google没有官方指导应用程序的架构，（除其他原因外）导致Android应用程序源代码的混乱。 实际上，即使在今天，我看到的大多数应用程序仍然不遵循OOP最佳实践，也没有显示明确的逻辑组织代码。
但是今天的情况却不同 – Google最近发布了与Android Studio完全集成的数据绑定库 ，甚至为Android应用推出了一套体系结构蓝图 。
两年前，在Android上很难find有关MVC或MVP的信息。 今天，MVC，MVP和MVVM已经成为Android社区的“热门词汇”，我们被无数的专家包围着，他们不断地试图让我们相信MVx比MVy更好。 在我看来，讨论MVx是否比MVy好是完全没有意义的，因为术语本身是非常模糊的 – 只要看看这个问题的答案，就会发现不同的人可以把这些缩写与完全不同的结构联系起来。
由于searchAndroid最佳架构模式的事实已经正式启动，我想我们将会看到更多的想法。 在这一点上，预测未来哪些模式（或多个模式）将成为行业标准是不可能的 – 我们需要拭目以待（我猜这是一年或两年的事情）。
但是，我可以高度自信地做出一个预测：数据绑定库的使用将不会成为行业标准。 我有信心说，因为数据绑定库（在其当前的实现中）提供了短期的生产力提升和某种forms的体系结构指导，但是从长远来看，这会使得代码不可维护。 一旦这个图书馆的长期影响将浮出水面 – 它将被放弃。
现在，尽pipe我们今天确实有一些官方的指导方针和工具，但我个人认为，这些指导方针和工具是最好的select（而且绝对不是唯一的select）。 在我的应用程序中，我使用自己的MVC体系结构实现。 它很简单，干净，可读和可testing，并且不需要额外的库。
这个MVC不仅与其他人有美容上的不同 – 它基于一个理论，即Android中的活动不是UI元素 ，这对代码组织有着巨大的影响。
因此，如果您正在为Android应用程序寻找一个遵循SOLID原则的良好架构模式，可以在我的post中find关于Android中MVC和MVP架构模式的描述 。
Android框架中使用的各种模式如下所示：
- 广播接收机使用观察者模式
- 远程服务调用使用代理模式
- 查看和查看组使用复合模式
- 媒体框架使用Facade模式
这里有一篇关于Android通用devise模式的文章：
创造型模式：
- 生成器（例如AlertDialog.Builder ）
- dependency injection（例如Dagger 2 ）
- 独生子
结构模式：
- 适配器（例如RecyclerView.Adapter ）
- 门面（例如改造 ）
行为模式：
- 命令（例如EventBus ）
- 观察者（例如RxAndroid ）
- 模型视图控制器
- 模型视图ViewModel（ 类似于上面的MVC模式 ）
以下Android类使用devise模式
1）查看持有人使用单身devise模式
2）意图使用工厂devise模式
3）适配器使用适配器devise模式
4）广播接收机使用观察者devise模式
5）查看使用复合devise模式
6）媒体框架使用外观devise模式
当我到达这个职位，它真的帮助我了解模式的例子，所以我已经使下表清楚地看到在Android框架中的devise模式及其示例
我希望你会发现它有帮助。
在通知的情况下， 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);
Android也使用ViewHolderdevise模式。
用于在滚动ListView的同时提高性能。
ViewHolderdevise模式使您能够访问每个列表项视图，而无需查找，从而节省宝贵的处理器周期。 具体来说，它避免了在ListView滚动过程中频繁调用findViewById（），这将使其平滑。
所有这些模式，MVC， MVVM ，MVP和Presentation Model都可以应用到Android应用程序中，但是没有第三方框架，组织良好的结构和清晰的代码并不容易。
MVVM源自PresentationModel。 当我们将MVC， MVVM和Presentation Model应用到Android应用程序时，我们真正想要的是有一个清晰的结构化项目，更重要的是unit testing。
目前，如果没有第三方框架，通常会有很多代码（如addXXListener（），findViewById（）等），这些代码不会增加任何业务价值。 更重要的是，你必须运行Androidunit testing，而不是正常的JUnittesting，这需要很长时间才能运行，并使unit testing有些不切实际。
由于这些原因，几年前我们开始了一个开源项目RoboBinding – Android平台的数据绑定表示模型框架。 RoboBinding帮助您编写更容易阅读，testing和维护的UI代码。 RoboBinding 不需要像addXXListener这样的不必要的代码 ，并将UI逻辑转换到呈现模型，这是一个POJO ，可以通过正常的JUnittesting进行testing 。 RoboBinding本身带有300多个JUnittesting，以确保其质量。
我想添加一个在Android Framework中应用的devise模式。 这是Asynctask实现中使用的半同步半asynchronous模式。 请参阅我的讨论
https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing
在Android中，“工作队列处理器”模式通常用于卸载应用程序主线程中的任务。
示例：IntentService类的devise。
IntentService接收Intents，启动一个工作线程，并根据需要停止该服务。所有请求都在一个工作线程上处理。
活页夹使用“观察者模式”用于死亡接收者通知。
