基于MVC架构模式的Android应用探索性研究外文翻译资料

基于MVC架构模式的Android应用探索性研究

摘要：移动应用程序开发现在是软件行业的重要组成部分，Android是最大的生态系统。安卓开发有自己的设计实践和模板（layouts、activities等）。开发人员还使用不同的既定架构模式来设计交互式软件，例如MVC、MVP和MVVM。他们根据自己的理解和经验使用这些模式。因此，这类模式的选择和实现因开发人员而异。据我们所知，没有任何工作可以全面了解这些模式在移动应用程序中的使用情况。此外，对于使用哪种模式以及使用这种模式设计移动应用程式的趋势没有明确的理解。在本文中，我们提出了一种自动方法来识别在给定的应用程序中主要使用哪种基于MVC的体系结构模式（MVC、MVP和MVVM）。为此我们通过一些启发式方法定义了这些模式中每一个在Android框架内的潜在实现。我们从Google Play商店下载了大量移动应用进行实证研究。毫不奇怪，我们发现流行的MVC模式占主导地位，MVP很少使用，而MVVM几乎没有使用，而且大量应用程序不遵循任何模式。实证研究还使我们能够按应用程序的领域、大小和最后更新日期分析这些模式的使用。我们观察到MVC是过去几年中使用最多的模式，并且它将继续流行，而小型应用程序大多不使用任何模式。

关键词：软件架构、架构模式、设计模式、移动开发、MVC、MVP、MVVM

1. 介绍

移动应用程序无疑是一个不断增长的市场。这些应用程序中绝大多数都在Android下运行，Android已成为占主导地位的移动平台，市场份额为88%。移动设备通常在内存、电池、计算能力、资源竞争等方面有更多的限制。为了应对这些，Android框架提出了很多机制和更加强调结构良好设计模式的架构组件，如Bagheri等人的研究所示[4]。Android开发人员必须结合这些机制，并决定如何使用它们来满足应用程序的要求。

这些选择队应用程序质量的影响怎么强调都不为过。特别是随着用户交互在几乎所有应用程序中都如此重要，使其与在表示层建立的模式，如MVC及其变体MVP和MVVM变得关系特别紧密。尽管这些模式在Android开发者社区中被广泛使用和讨论，但对于它们的使用或哪种模式最适合Android应用并没有达成共识[9,27,29,35]。事实上，没有可用的数据或研究可用于决定哪种模式适合哪种类型的应用程序。此外，这些模式中的每一种都可以在Android框架内以不同的方式实现。

在这种情况下，需要研究分析这些基于MVC模式在Android应用程序中实现的方式，这些数据对于概述移动应用程序的设计趋势以及更好地理解Android应用程序的特征与基于MVC模式之间的关系至关重要。最近关于移动应用程序的工作包括[21,23-25,27,30,32]和[4]。然而这些工作要么集中在这些模式的可能实现上[23,25]、手动识别和比较[27]、架构恢复[4]或自动识别反模式和代码异味[21,24,30,32]。据我们所知，目前还没有工作支持自动检测Android应用程序中的表示层架构模式，例如MVC、MVP和MVVM。因此，这项工作旨在回答以下研究问题：

RQ1：基于MVC模式在Android应用程序中的使用频率是多少？

RQ2：哪些Android应用程序使用基于MVC模式？

为了回答这些问题，我们提出了一种称为Rimaz的方法来识别Android应用程序中主要的基于MVC模式，该方法基于在Android中考虑MVC变体的可能实现的启发式算法。使用Rimaz，我们对来自Google Play商店的5480个应用程序进行了研究，以了解与使用MVC变体相关的Android环境。因此，我们的贡献基本上又两个方面：

1) 一种基于启发式方法来识别Android MVC变体

2) 一项用于回答有关在Android应用程序中使用哪类模式的实证研究

本文的其余部分安排如下：第2节介绍相关工作以及有关Android和基于MVC模式的一些关键概念。第3节介绍了Rimaz，这是我们基于启发式的方法。第4节和第5节提供了我们对方法的评估。第6节总结了本文并讨论了未来的工作。

1. 背景及相关工作

本节简要介绍Android框架及其关键组件。然后描述了三中架构模式（MVC、MVP、MVVM）及其在Android中的实现

2.1 安卓框架

Android应用程序开发围绕关键构建块进行组织，开发人员和设计人员需要了解这些构建块。这些应用程序组件（例如Activity、Service、BroadcastReceiver和ContentProvider）充当Android应用程序的入口点。活动（Activities）是定义用户交互屏幕的关键组件，而其他三个是处理后台任务（Services）、通知（Broadcast receivers）和访问共享数据（Content providers）的匿名组件。除了Activities之外，还有一些较低级别的组件，附加到它身上，比如帮助用户交互的Fragments和Dialogs。更底层的还有UI对象，例如Button和EditText。

所有这些组件都有助于实现Android应用程序。应用程序的概念在Android中有明确定义，并在清单文件（AndroidManifest.xml）中声明了一个顶级应用程序类，其中包括有关其可见Activities、Services、Broadcast receivers和Content providers的信息。应用程序源代码与数据和资源捆绑在一起，使用各自的语言编译器和Android SDK编译。这会生成一个名为APK（Android应用程序包）的存档文件，其中包含安装和运行应用程序的所有必要信息[16]。

应用程序类和Activities、Fragments、Dialogs是影响具有用户界面的移动应用程序的行为和生命周期的主要组件。由于这项工作的目标是研究表现层的模式，我们将主要关注使用这些组件的Android应用程序。

2.2 MVC、MVP和MVVM

可维护和高质量交互式软件的开发需要在底层数据、其表示和操作之间进行清晰的分离。因此，基于MVC的架构设计模式被广泛用于此类软件[6]。然而，不同的观点导致了不同的基于MVC模式。

图1 MVC、MVP和MVVM

2.2.1 MVC

MVC模式于1979年提出，旨在将业务逻辑与表示层分离[31][8]。它定义了三个主要层。首先，Model：基本上是一组代表知识、信息的实体和一组处理更新和访问这些信息的规则[31]。为了确保与其他层的低耦合，Model不应该知道其他组件，但可以向它们发送有关其对象状态的通知[6][7]。其次，View：负责提供模型的可视化表示。视图显示通过发送查询从Model检索的数据，并且可以通过消息更改其状态。第三，Controller：是应用程序的要入口点，它操作视图并将用户的交互转换成Model[31]。此外，Controller直接与Model通信并且必须能够改变其状态[6]。图1(a)显示了原始MVC架构的三个组件并描述了它们之间的联系。自推出以来，MVC随着新开发框架的出现而发展，许多改变使模式适合目标框架，从而产生新的变体。

2.2.2 MVP

MVP（图1(b)）是MVC架构的一种变体，于90年代初引入。它在领域层和用户界面之间带来了更多的解耦。

与MVC相比，MVP中的Presenter比MVC中的Controller更孤立于底层系统，并且应该对系统一无所知[5]。Model本质上具有相同的职责，而View处理操作系统组件或用户界面的操作，仅将操作Model实体的操作委托给Presenter。如果Presenter需要对用户界面进行可视化更改或与底层操作系统进行交互，则它应该调用实现此需求的View方法[12]。

2.2.3 MVVM

MVVM是MVP模式的演变[22]。如图1(c)所示，它旨在实现用户界面和以ViewModel为代表的中间层之间更多的解耦。这两者之间的通信完全通过双向数据绑定通知完成。

通常用声明性语言（通常是XML变体）编写的视图表示用户界面。它尽可能地被动，仅声明小部件和用户界面对象，并将所有逻辑委托给其支持的ViewModel，从中检索任何类型的更新[28]。ViewModel只是一种View的Model。它定义并实现用户输入事件，转换Model数据并使其由视图显示。重要的是，ViewModel应该完全不知道它对应的View。不应在ViewModel中声明或使用对View的引用。ViewModel应该随时准备好与任何其他View实体一起使用，而不会破坏代码[28]。与其他两种模式相比，Model作用保持不变。

2.3 Android应用程序中基于MVC模式的实现

MVC是Android 采用的第一个模式。然而，它在Android应用程序中的实现仍存在争议。其中心是对Controller的解释[35]。据说它是入口点和处理用户和视图交互并将它们转换为数据层的层。

一些开发者认为Activity是扮演Controller角色的主要组件，因为它是应用程序的主要入口和声明输入事件最自然的地方。其他开发人员认为Activity、Fragments和Dialogs应该被视为View的一部分，或者至少是View组件的帮助者，而Controller组件应该是单独的类。这两种选择都得到了强有力的论据支持，在现实世界中得到了很好的使用，并且应该被检测方法考虑在内。

另一方面，MVP可以直接在Android上实现。按照标准定义，MVP将事件的声明保存再View中，并将它们执行的工作委托给Presenter，Presenter应该将平台组件和功能的操作委托给View。为了实现这一点，View有一个引用Presenter的字段，反之亦然。在Android世界中，与MVC相反，Activity、Fragments和Dialogs被视为View的一部分。图2和图3简单地说明了Activity与其对应的Presenter之间的关系。

图2 演示者类和活动之间的关系

图3 活动与演示者类之间的关系

MVVM，在Android世界中姗姗来迟。然而，自从谷歌在2017年引入新的架构组件以来，它已经有了更大的知名度，现在是Android应用程序的推荐设计[18]。Android现在通过ViewModel[20]和LiveData[19]等类型简化了MVVM的使用。谷歌直到2016年才开始支持完全高级的数据绑定[15]，因为开发人员以前必须使用第三方库来实现MVVM。ViewModel由为每个View组件扮演数据绑定上下文角色的类表示。将View组件绑定到ViewModel类，生成定义所有绑定操作并为运行时准备的中间类[15]。事件从布局文件绑定到相应的ViewModel类作为方法，它们稍后将使用传统的监听器模式在数据绑定生成的类中重新定义[15]。

2.4 相关工作

最近，有一些工作是针对移动应用中基于MVC模式的手动分析，只有一个处理其架构恢复。事实上，除了反模式和代码异味之外，没用专门与移动应用中模式自动检测相关的工作。现将相关工作报告如下。

2.4.1 移动应用程序中的设计基于MVC模式

<p

剩余内容已隐藏，支付完成后下载完整资料</p

英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[596213]，资料为PDF文档或Word文档，PDF文档可免费转换为Word