Android使用了哪些架构模式?

21 浏览
0 Comments

Android使用了哪些架构模式?

已关闭。此问题需要更加具体化。它目前无法接受答案。


想要改进这个问题吗?通过编辑这个帖子,更新问题以便它只关注一个问题。

改进这个问题

我正在研究移动平台,我想知道Android使用了哪些设计模式?

比如,在iOS中,Model-view-controller与委托以及其他模式一起非常广泛地使用。

Android使用哪些模式,以及在哪些方面使用?

编辑

我不是在问内核、dalvik等中使用了哪些设计模式,而是有关应用程序开发人员在开发应用程序时会遇到的模式。

admin 更改状态以发布 2023年5月25日
0
0 Comments

2018年11月更新

在多年来工作和写关于Android中的MVC和MVP的博客后(请见下面的答案正文),我决定以一种更综合易于理解的方式来记录我的知识和理解。

所以,我发布了一门关于Android应用架构的全面视频课程。所以,如果你有兴趣掌握Android开发中最先进的架构模式,可以在这里查看全面课程

本答案已于2016年11月进行更新以保持其相关性


看起来你正在寻找架构模式而不是设计模式

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

由于Android应用程序(和大多数AOSP)都是用Java编写的,Java是面向对象的,我认为你很难寻找在Android上没有用过的单个OOP设计模式。

架构模式则不涉及特定的软件任务,而是旨在基于所讨论的软件组件的用例提供软件组织的模板

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

由于你在问题中提到了MVC,我猜测你正在寻找架构模式。

Enter image description here


历史上,Google没有关于应用程序架构的官方指南,这(以及其他原因)导致了Android应用程序源代码的混乱。事实上,即使是今天,大多数应用程序仍然不遵循OOP最佳实践,也没有明确的代码逻辑组织。

今天情况有所不同 - 谷歌最近发布了与Android Studio完全集成的Data Binding库,并发布了一组用于Android应用程序的架构蓝图。两年前,在Android上发现有关MVC或MVP的信息非常困难。今天,MVC,MVP和MVVM已成为Android社区中的“流行词”,我们周围有着无数专家不断地试图说服我们MVx比MVy好。在我看来,讨论MVx是否比MVy更好完全没有意义,因为这些术语本身非常模糊-只需查看对这个问题的答案,你会意识到不同的人可以将这些缩写与完全不同的结构联系起来。由于搜索Android的最佳架构模式已经正式开始,我认为我们即将看到更多的想法光芒。在此时此刻,真的无法预测哪种模式(或模式)将成为未来的行业标准-我们需要等待和看(我想这是一两年的事)。然而,有一种预测我可以高度自信地做出:Data Binding库的使用不会成为行业标准。我有信心说这是因为Data Binding库(在其当前实现中)提供了短期生产力增益和某种架构指南,但它会使代码在长期内难以维护。一旦这个库的长期效应浮出水面-它就会被抛弃。尽管今天我们确实有了某种官方的指导方针和工具,但我个人认为这些指导方针和工具并不是最好的选择(它们绝对不是唯一的选择)。在我的应用程序中,我使用自己实现的MVC架构。它简单,清晰易读,易于测试,并且不需要任何额外的库。这个MVC不仅在外观上与其他MVC有所不同-它基于一个理论:Android中的Activities不是UI元素,这对于代码组织有巨大的影响。因此,如果您正在寻找符合SOLID原则的Android应用程序的良好架构模式,可以在我的有关Android中MVC和MVP架构模式的帖子中找到其中一种的描述。

0
0 Comments

我尝试过使用 model–view–controller (MVC) 和 model–view–presenter 架构模式进行 Android 开发。我的发现是 model–view–controller 工作得很好,但有一些“问题”。这归结于您如何看待 Android Activity 类。它是控制器,还是视图?

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

这意味着,当您使用 MVC 模式时,您的控制器实际上将是伪视图控制器。因为它处理向用户显示窗口,利用通过 setContentView 添加的附加视图组件,并处理至少各种活动生命周期事件的事件。

在 MVC 中,控制器应该是主要入口点。但是,当将其应用于 Android 开发时,是否是这种情况还有一些争议,因为活动是大多数应用程序的自然入口点。

基于这个原因,我个人发现 model–view–presenter 模式非常适合 Android 开发。因为在此模式中,视图的角色是:

  • 作为一个入口点
  • 呈现组件
  • 将用户事件路由到 presenter

这使您可以像以下方式实现您的模型:

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

Presenter - 这将处理您的模型与视图之间的通信,将其视为通往模型的入口。这意味着,如果您有一个表示天知道什么的复杂域模型,并且您的视图只需要该模型的一个非常小的子集,则 presenter 的工作是查询模型,然后更新视图。例如,如果模型包含一段文本、一个标题和一个字数统计,则在给定视图中,您只需要在视图中显示标题。那么 presenter 将从模型中读取所需的数据,然后相应地更新视图。

模型 - 这应该基本上是您的完整领域模型。希望它也能帮助使您的领域模型更加“紧凑”,因为您不需要处理上述情况的特殊方法。

通过完全将模型与视图分离(通过使用 presenter),还可以更直观地测试您的模型。您可以对您的域模型进行单元测试,还可以对您的 presenter 进行单元测试。

尝试一下。我个人认为它非常适合 Android 开发。

0