英语原文共 57 页，剩余内容已隐藏，支付完成后下载完整资料
使用MVP，消除了视图和模型之间的耦合。模型对表示器一无所知，反之亦然。MVP交互如图7所示。
图7.MVP组件间的交互
与MVC不同，MVP流从视图组件开始。视图捕获用户输入事件并将其转发给表示器。对于简单的事件，表示器作出决定并更新视图。如果是一个复杂操作，表示器会向模型来检索相关数据，然后更新视图有时，用户的输入会对模型中的数据产生影响。在这种情况下，视图不会直接影响模型，而是要求表示器更新模型。
3.2.3安卓中MVP的实现
MVP架构有两种基于表示器职责的变体:监控控制器和被动视图[17]。监督控制器版本是MVP的原始版本。在这个版本中，视图将控制简单的部分逻辑，而表示器将控制更复杂的逻辑。被动视图更喜欢将视图视为虚拟视图，并将所有逻辑传递给表示器。
Android采用被动视图。但是对于MVP的实施并没有具体和正式的规定。幸运的是，谷歌在GitHub[18]中发布了MVP开源示例。他们称这个示例Android架构蓝图为[beta版]。这是对MVP应用规则正式化的一次尝试。因此，这篇论文以该样本作为标准。
图8所示的UML类图阐明MVP的实现。模型和视图部分与MVC中的一致，表示器是普通java对象
图8.MVP类图
基础接口。基础视图和基础表示器是所有视图和表示器的父类。这两个基础接口确保了表示器和视图元素绑定在一起并加载所需的数据。基础视图接口是视图组件的基类，它有一个最重要的方法setPresenter()来设置这个视图的presenter。基础表示器接口是Presenter组件的基本接口。最重要的方法是在onStart()中准备要在视图中显示的数据。基础表示器中的onStart()方法通常在Fragment中的onResume()方法中调用。
Contract类是用来管理一个特定的视图和它的表示器之间的接口，它是视图接口和表示器接口的组合。视图只能调用Presenter接口中显示的Presenter方法，反之亦然。
Fragment/Activity 和xml布局都是视图。大多数情况下，Fragment 提供视图职责。活动的目的是创建Fragment(视图)和Presenter的实例，然后连接这两个组件。
所有类的交互流的解释如下。
1. 使用视图和表示器绑定调用活动类。
a.片段实例是在Activity OnCreate()方法中创建的。
表示器的实例是在调用表示器结构方法时创建的。在此步骤中，视图和表示器在此构造函数中相互绑定。1)视图实例作为参数传递，因此视图被绑定到这个表示器。2)调用视图的setPresenter方法，并传递这个presenter参数，这样presenter就被绑定到View。
2. 该视图对用户可见，表明片段处于恢复状态。onStart()方法通常在onResume()方法中调用来加载数据。
3.3 模型-视图-视图模型
模型-视图-视图模型(MVVM)架构由架构师John Grossman在他的博客[19]中解释。该架构在Microsoft Silverlight和WPF中得到了应用。它也基于模型-视图-控制器架构。
3.3.1 MVVM架构
模式/视图/视图模型(MVVM)体系结构是一种为现代UI开发平台量身定制的体系结构，在现代UI开发平台中，视图是设计人员的职责，而不是传统开发人员的职责。“[19]
MVVM体系结构有三个组件，即名称状态、模型、视图和视图模型。视图组件显示应用程序的UI。在MVVM中，它应该对设计人员更友好，可以由设计人员而不是代码开发人员轻松实现。模型表示数据，与前面的体系结构中解释的模型相同。视图模型，即视图的模型，用于管理视图的状态。它将向视图传递数据和操作，并管理视图的逻辑和行为[20]。一个好的View-Model组件应该在命名和类型上只包含特定状态数据而不是特定视图数据。举个例子，当我们想要用保存按钮来保存数据，我们应该用特定状态数据canSave，而不是将变量命名为isSaveButtonEnabled。
图9[20]解释了这些组件之间的交互。视图模型和视图之间的连接比MVP架构中复杂。有两种类型的连接:传统连接和数据库连接。
传统的连接和MVC和MVP类似，视图模型组件将在java代码中更改视图。
图9.MVVM的交互
数据绑定是MVVM中引入的一种新机制。它允许视图直接绑定到视图模型的属性和操作。使用数据绑定，视图模型组件不必通过代码通知视图的更改，视图知道数据已加载，并通过视图本身显示数据。例如，在MVP和MVC架构中，数据加载后，表示器和控制器将在代码中设置视图。使用数据绑定机制，视图被绑定到该数据，当数据加载时，视图将自动更改。
视图和视图模型间的数据绑定可以是定向的也可以是双向的。当视图中的数据绑定改变时视图模型组件中的数据也会知道。这种被称作为“属性绑定”的绑定，是一种双向绑定。还有一种数据绑定称为“操作绑定”，它是定向的。在视图模型中创建的操作被绑定到视图中的小部件。这种绑定类似于HTML表单视图中的JavaScript代码。当用户单击表单中的save按钮时，它将调用JavaScript代码中预先定义的方法。通过这种方式，在视图-模型组件中，我们不需要编写代码来捕获单击事件。
3.3.2 MVVM 在安卓中的应用
安卓中的数据绑定
为了演示数据绑定在Android中是如何工作的，本节展示了来自官方Android开发网站[21]的指导示例。在Android中，要启用数据绑定，需要导入第三方库——数据绑定库。databinding库页面解释了[21]的详细用法。在本节中，只解释数据绑定和事件绑定，它们也分别称为属性绑定和操作绑定。
要在Android中使用数据库库，我们需要基于当前的Android实现进行一些更改。首先，导入库。其次，在OnCreate()方法中展开布局文件时，在Activity类中设置绑定对象。第三，在相关的xml文件中，声明了一个带有绑定变量的新数据段。
例如，应用程序将显示用户名。在活动中，使用数据绑定方法而不是默认的setContent()方法来扩展布局文件。在这之后，我们得到对这个绑定的引用。然后，通过引用将姓为User、名为Test的用户对象传递给xml文件。
然后，在基本的xml文件之上，添加一个新部分来声明将在这个XML文件中使用的相关对象类和方法类。在小部件属性中，用户使用@{}来引用相关事件和属性。
图10.MVVM在安卓中的应用
图10展示了Android中MVVM架构的UML图。从已发布的蓝图来看，MVVM架构类似于MVP架构。它是MVP架构中数据库库的改进。主要的区别是视图xml文件与视图模型/和模型类之间的依赖关系(用橙色线表示)。查看xml文件需要知道模型中的结构。在上面的例子中，它需要理解User对象中有firstName、lastName和isFriend属性。类似地，为了调用方法，XML文件需要知道类名MyHandler()及其方法。
4 可测试性
可测试性，，在ISO/IEC 25010标准中，被定义为“为系统、产品或部件建立测试标准,并执行测试以确定是否满足这些标准的有效性和效率的程度”， 它指出了软件测试[22]的难易程度。
测试是移动开发中必不可少的活动。如前所述，手机app的升级频率非常高，大约每月1 - 4次发布。快速开发通常是以质量[23]为代价的。2013年的一篇论文显示，经过访谈和调查，移动开发面临的关键挑战之一就是没有足够的工具支持测试[24]。但是现在，Android平台上有多个测试库，从另一个角度证明了测试的重要性。
4.1 安卓的测试
Android开发指南将测试分为四种类型:本地单元测试、仪表化单元测试、应用程序测试中的组件和跨应用程序测试。对于每种测试类型，都有专门的支持库。
本地单元测试和仪表化测试称为单元测试，用于测试应用程序的一部分。本地单元测试在本地JVM机器上运行。它与Java项目中的测试相同。仪表化的单元测试与android特定的环境相关，例如模拟器或物理设备。这个特性意味着插装测试比本地单元测试花费更多的时间。因为要运行仪表化测试，我们必须每次启动模拟器/设备并安装Android应用程序。
剩下的两个测试称为集成测试。app测试中的组件关注用户和UI之间的交互。当用户单击按钮或输入内容时，这类测试将验证输出是否与预期的相同。跨应用程序测试集中于使用不同应用程序的测试。例如，一些应用程序允许用户在系统日历中添加日程，一些应用程序可以控制屏幕的亮度。
4.2 可测试性标准
到目前为止，已经有一些研究探索了影响可测试性的因素。
Freedman提出了域可测性的概念，域可测性是可观测性和可控制性[25]的结合。可观察性要求对于相同的输入参数，输出总是相同的。可控性要求从输出集推导出的输入集与原始输入集相同。如果一个软件组件是可控和可观察的，那么它就是可测试的。一个可测试的软件组件有4个属性:小而容易构造的测试集、非冗余的测试集、易解释的测试输出以及易跟踪组件中的错误。
Baudry和Le Traon声称软件的可测试性受到三个参数的影响:全局测试工作、可控性和可观察性[22]。全局测试工作是指实现测试目标的测试工作，包括测试集大小、生成测试数据的易用性和验证测试结果[22]的易用性。
Binder分析了面向对象系统中的各种可测试性因素，并用鱼骨图[26]表示了所有这些因素。确认了六个主要因素:流程能力、内置测试、测试套装、测试支持环境表示和实现(需要解释)。Bruntink和Arie通过估计测试用例的数量来评估类的可测试性，并且很容易创建单个测试用例[27]。
到目前为止，已经确认了几个可测试性因素:可观察性、可控性、测试用例的大小、构建测试用例的工作、易于解释测试结果和易于定位错误。
可见性和可控性在本文中并不适用。第3节中的体系结构分析显示，三个体系结构的主要区别来自于组件的分离。在解耦过程中，方法和函数被移动到不同的组件。但功能细节保持不变。如果方法和功能在一个体系结构中是可观察和可控的。在其他体系结构中应该是相同的，因为函数/方法实现没有更改。
在不同的架构中解释测试用例的难易程度是一样的。在第三方库的帮助下，在运行测试用例之后直接给出结果。在Android Studio中，通过的测试用例用绿色标记，而失败的测试用例用红色标记并附上原因。然而，不同的测试类型消耗不同的时间。显然，在JVM上运行的测试比在模拟器上运行的测试花费的时间要少。因此，我们将这个因素更改为运行测试用例所消耗的时间的新因素。
易于定位错误，当有错误发生的时候，android studio会显示错误的路径。这个过程在IDE中是自动的。如果开发人员想知道错误的更多细节。另一种方法是设置断点来逐步跟踪错误。因此，我们使这个因素在Android中更加具体—使用断点进行调试很容易。
简而言之，我们使用了三个标准来评估可测试性:(1)测试用例的大小。测试用例越少的架构越好。(2)运行测试用例所消耗的时间——使用较少测试工具的应用程序所消耗的时间更少。(3)容易调试与断点-易于开发人员调试应用程序与断点。
4.3 评价
4.3.1 MVC
相比之下，MVC中的可测试性因素被当作标准。然后我们将尝试将MVP和MVVM中的因素与这些标准进行比较，看看它们是比MVC更好还是更差。
4.3.2 MVP
测试用例的大小与MVC中的相同。当两个应用程序具有相同的功能时，它们的测试用例的大小是相同的。
运行测试用例的消耗时间:一些方法与片段/活动分离并放在演示器类中，即纯Java类。换句话说，一些UI测试用例被转换为单元测试。 仪器化测试较少，但本地单元测试较多。 因此，总测试时间减少。
易于使用断点进行调试：总的来说，它与MVC相同。 然而，在MVP中，一些方法从Fragment / Activity移动到表示器中。断点会出现在两个类中。因此，开发者必须在这两个类之间连续的导航，这会让调试不那么方便。
4.3.3 MVVM
测试用例的大小:本地单元测试:从UML类图中我们可以看到，presenter中的方法比MVP中的方法要少。因此，单元测试、仪表化测试中的测试用例更少:与MVP相同
运行测试用例消耗的时间：基于本地测试用例较少的事实，总的消耗时间会比MVP少。
易于使用断点进行调试：除了Fragment / View和Presenter之外，数据分为三个文件，布局文件包含部分模型数据。 目前。 布局xml文件不支持断点。 调试布局文件中的错误更加困难。
4.3.4 结果评价
表1总结了三种体系结构的可测试性。 在表中，我们将MVC的可测试性当作标准。 将其他架构中的结果与MVC进行比较。 总的来说，对于可测试性，MVC lt;MVVM lt;MVP.
表1.MVC、MVP和MVVM的可测试性
<strong
全文共7131字，剩余内容已隐藏，支付完成后下载完整资料</strong
资料编号：[60]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
