Android上使用哪些设计模式?

我正在做一个关于移动平台的小型研究,我想知道Android中使用了哪些设计模式?

例如在iOS Model-view-controller中,与代理和其他模式一起使用非常广泛。

Android使用哪些模式和特定位置?

编辑

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


我尝试使用模型视图控制器(MVC)和模型视图演示者设计模式进行android开发。 我的发现是模型视图控制器的工作正常,但有几个“问题”。 这一切都归结于你如何看待Android Activity类。 它是控制器还是视图?

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

这意味着,当你使用MVC模式时,你的控制器实际上是一个伪视图控制器。 由于它正在处理向用户显示一个窗口,其中包含通过setContentView添加的其他视图组件,并且还处理至少各种活动生命周期事件的事件。

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

因此,我个人发现模型 - 视图 - 演示者模式非常适合Android开发。 由于该观点在这种模式中的作用是:

  • 作为切入点
  • 渲染组件
  • 将用户事件路由到演示者
  • 这允许你像这样实现你的模型:

    查看 - 这包含您的UI组件,并处理它们的事件。

    演示者 - 这将处理您的模型和视图之间的通信,并将其视为您模型的入口。 意思是,如果你有一个复杂的领域模型代表,上帝知道什么,而你的观点只需要这个模型的一个非常小的子集,那么演示者的工作就是查询模型,然后更新视图。 例如,如果您的模型包含一段文字,一个标题和一个字数。 但是在给定的视图中,您只需要在视图中显示标题。 然后,演示者将读取模型中需要的数据,并相应地更新视图。

    模型 - 这应该基本上是你的完整领域模型。 希望这将有助于使您的域模型更加“紧密”,因为您不需要特殊的方法来处理上述情况。

    通过将模型从视图中分离出来(通过使用演示者),测试模型也变得更加直观。 您可以为您的域模型进行单元测试,并为您的演示者进行单元测试。

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


    此答案已更新,以便于2016年11月保持相关


    看起来你正在寻找建筑模式而不是设计模式。

    设计模式旨在描述程序员可能实现的处理一组特定软件任务的一般“技巧”。 例如:在OOP中,当需要一个对象通知一组其他对象有关某些事件时,可以使用观察者设计模式。

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

    另一方面, 架构模式并不涉及特定的软件任务 - 它们旨在基于所讨论的软件组件的用例为软件组织提供模板

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

    既然你在提到的问题中提到了MVC,我猜想你正在寻找的是架构模式。

    在这里输入图片说明


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

    但是今天的情况却不同--Google最近发布了与Android Studio完全集成的数据绑定库,甚至为Android应用程序推出了一套体系结构蓝图。

    两年前,在Android上很难找到有关MVC或MVP的信息。 今天,MVC,MVP和MVVM已成为Android社区的“热门词汇”,我们被无数专家包围着,这些专家经常试图让我们相信MVx比MVy更好。 在我看来,讨论MVx是否比MVy更好是毫无意义的,因为这些术语本身非常模糊 - 只要看看这个问题的答案,就会发现不同的人可以将这些缩写与完全不同的结构联系起来。

    由于搜索Android最佳架构模式的事实已经正式启动,我想我们将会看到更多的想法。 在这一点上,预测未来哪种模式(或多种模式)将成为行业标准是不可能的 - 我们需要拭目以待(我猜这是一年或两年的问题)。

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


    现在,虽然我们今天确实有一些官方的指导方针和工具,但我个人认为,这些指导方针和工具并不是最好的选择(而且它们绝对不是唯一的选择)。 在我的应用程序中,我使用自己的MVC体系结构实现。 它很简单,干净,易读和可测试,并且不需要任何额外的库。

    这个MVC不仅在美观上与其他人不同 - 它基于一个理论,即Android中的Activities不是UI元素,这对代码组织有着巨大的影响。

    因此,如果您正在寻找遵循SOLID原则的Android应用程序的良好架构模式,可以在我的帖子中找到关于Android中MVC和MVP架构模式的描述。


    Android框架中使用了各种模式,如:

  • 广播接收器使用观察者模式
  • 远程服务调用使用代理模式
  • 查看和查看组使用复合模式
  • 媒体框架使用Facade模式
  • 链接地址: http://www.djcxy.com/p/30201.html

    上一篇: Which design patterns are used on Android?

    下一篇: Why use a controller and a presenter together?