CN106648682A

CN106648682A - 一种面向嵌入式系统开发的动态数据通用框架

Info

Publication number: CN106648682A
Application number: CN201611246115.4A
Authority: CN
Inventors: 郭克华; 肖喆; 肖一喆
Original assignee: Central South University
Current assignee: Central South University
Priority date: 2016-12-29
Filing date: 2016-12-29
Publication date: 2017-05-10
Anticipated expiration: 2036-12-29
Also published as: CN106648682B

Abstract

本发明公开了一种面向嵌入式系统开发的动态数据通用框架，包括：资源管理器，用于负责在全局范围内提供数据；虚拟加载器，用于动态加载dex文件中的类或者外部文件中的类，通过资源管理器获取所需资源；视图绑定器，用于将虚拟加载器提供的不同类型的数据绑定到对应的控件中。本发明一方面可以减少代码量，增加代码可靠性；另一方面可以使逻辑结构变得清晰，将数据业务流程和其他逻辑(视图逻辑等)分开，提高代码的可测试性。

Description

一种面向嵌入式系统开发的动态数据通用框架

技术领域

本发明涉及计算机领域，特别是一种面向嵌入式系统开发的动态数据通用框架。

背景技术

在计算机系统中，框架是一个指定何种程序可以或者应该构建在此之上，以及它们应该如何通信的结构层面。有些系统框架同时包含了实际的程序，同时定义了软件接口，或者提供开发工具来使用此框架。框架既可以是系统中的一套方法，来限定软件如何和框架之间进行通信，也可以是操作系统上的某一层，或者是一个应用程序的子系统层，或者可以是来规范化统一化网络通信，等等。一般来说，框架比协议更具体，而比结构更加抽象。

框架的目标是用于提供一个普适性的结构，帮助开发者来减少重复的工作并且复用已有的代码。

框架具有以下几个优点：

1)提高开发效率

对于某个特定的任务，实现方法往往是一致的，而在系统的设计之初，为了方便其扩展，它提供的原有接口因为可扩展性的考虑而牺牲了易用性；同时，对于某个特定系统业务，开发者需要多次使用。在这些情况下，开发人员需要编写重复的代码。基础的业务以及特定的业务往往具有共性，因此，通过成熟的开发框架，可以减少公共部分代码的编写，并且减少调试的时间，可以让开发人员集中于其他逻辑的开发。

2)易于扩展

通过框架定义的接口，开发人员可以方便地对框架进行扩展，以支持新的业务。在某些场景之下，业务具有相似性，因此，开发人员可以对框架进行进一步扩展，以支持更多的业务。同时，框架可以作为系统基础架构，并在此之上进行全新架构的开发。

3)可验证性强

由于框架的使用具有广泛性以及可靠性，因此，开发人员可以将精力放在逻辑代码中。

目前，大多数框架只针对于服务端中的资源。它们并没有考虑其他资源，例如客户端本地数据库、本地服务等资源。在工业界中，为了提高用户体验，绝大多数的应用采用了分层的数据展示模式，因此，一个面向多资源的架构是非常有必要的。

在工业界，第三方公司或个人开发了许多Android平台的开发框架。

AndroidAnnotations提供了视图、资源的注入，事件绑定，并提供了一个简化的UI线程模型。AndroidAnnotations简化了视图资源注入过程以及事件绑定，简化了线程的使用。但是它没有很好的做到逻辑的分离。在示例代码中可以看到，所有的逻辑都在交互界面(Activity)中实现，容易使Activity变得臃肿。同时，AndroidAnnotations只提供了初始化的状态，在交互阶段没有提供更多的功能。它更多提供的是依赖注入的功能，而没有做到结构的分离。

Spring for Android是Spring框架的扩展，用于简化Android本地应用程序的开发。它提供了一个REST客户端，用于处理REST请求，并直接转化成一个可重用组件(JavaBean)。Spring for Android提供了一个简单的REST客户端，并且仅限于此。

RxAndroid是Reactivex在Android平台上的扩展，它是一个事件驱动的、异步的框架，可以让开发者在Java中进行函数响应式编程，提供一种组合式的编程方法，并提供了专门出错处理，适用于处理并发问题。同时，RxAndroid结合了Android的特性，提供了UI线程和非UI线程的交互功能。RxAndroid为Android编程提供了事件驱动的框架，通过监听事件的模式，减少代码的耦合度。RxAndroid提供了一种基于事件驱动的编程方式，并没有针对数据处理、测试提供系统的架构，没有针对Android工程的系统结构提供优化，应用RxAndroid的开发依然存在着胖Activity的问题。

jQuery Mobile是一个移动开发框架，是jQuery在移动设备上的分支，包含了一套核心库，并且提供了一个完整、统一的UI框架。jQuery Mobile的主要使用方式为标记，通过标记在页面中绑定数据展示方式。然而jQuery Mobile是前端的开发框架，并没有针对多目标资源进行设计。

ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架。其开发宗旨是简单、快速的进行Android应用程序的开发，包含AndroidMVC、简易SQLite ORM、IOC模块、封装Android HttpClitent的HTTP模块,具有快速构建文件缓存功能，无需考虑缓存文件的格式。同时，该框架还包括了一个手机开发中经常应用的实用工具类，如日志管理，配置文件管理，android下载器模块，网络切换检测等等工具。该框架是一个工具类的集合，并没有对系统构建提出解决方式。

LoonAndroid是一个自动注入框架，同时提供了实现了多重缓存、自动回收功能的图片加载框架，封装了一个网络请求模块。该框架集成了EventBus框架，让开发人员可以通过事件监听的方式实现模块间的解耦，同时提供了一系列的工具类。

然而，这些框架都是针对某个或某些特定问题的框架，并没有在整个系统层面上进行设计。

发明内容

本发明所要解决的技术问题是，针对现有技术不足，提供一种面向嵌入式系统开发的动态数据通用框架。

为解决上述技术问题，本发明所采用的技术方案是：一种面向嵌入式系统开发的动态数据通用框架，包括：

资源管理器，用于负责在全局范围内提供数据；

虚拟加载器，用于动态加载dex文件中的类或者外部文件中的类，通过资源管理器获取所需资源；

视图绑定器，用于将虚拟加载器提供的不同类型的数据绑定到对应的控件中。

所述资源提供器的工作流程包括：

1)获取所需加载数据对应的URI；

2)根据对应的URI获取数据；

3)实体从资源提供器中取回数据并在虚拟加载器所加载的界面需要的时候调用使用。

根据对应的URI获取数据的具体实现过程包括：

1)提供统一资源标识符URI、接收UI线程回调的对应接口、资源提供器；

2)通过检索资源提供器获得数据对象o；

3)如果该数据对象o为空，则从资源提供器中获取新的替代资源P，进入步骤4)；如果数据对象o不为空，则UI线程处理数据对象o；

4)如果资源P为空，则该线程处理失败；如果资源P不为空，则处理该数据P与UI线程。

所述实体包括请求-响应范式实体Poster、数据加载实体Director以及数据获取实体Multiple。

所述虚拟加载器的工作流程包括：

1)根据交互界面activity名称在最小可替换单元MRU数据库中进行查询，如果本地中存在此MRU，则加载该MRU，否则，执行原有activity；

2)根据不同类别的最小可替换单元MRU，分别进行不同的替换：

第一类替换：开发者需要某个资源时，绕过索引系统，使用一个标识符identifier来对资源进行重新导向，实现第一类替换的MRU模块使用对象名绑定；

第二类替换：通过类加载器ClassLoader来加载外部存储空间中的目标交互界面Activity，当应用程序需要加载一个特定的界面Activity时，虚拟加载器在本地数据库中查找是否有相应的最小可替换单元MRU，当查找到此最小可替换单元MRU时，虚拟加载器加载一个代理界面Activity作为代理，并通过类加载器ClassLoader来加载最小可替换单元MRU中的目标界面Activity，并把它作为一个普通的，不受界面管理器ActivityManager管理的类；所有目标界面Activity中的生命周期通过界面动态加载代理界面ProxyActivity来实现；当目标界面Activity请求任何资源时，实际访问代理界面ProxyActivity的资源，并重新定向到外部存储中的资源。

所述视图绑定器的工作流程包括：

1)获得用户使用注入器注入的实体O(包括同步响应实体Poster或异步响应实体Director、Loader、Multiple)、资源提供器与数据的对应关系矩阵：

2)检查将要绑定的资源是否符合视图所特定的变量类型；

3)将资源提供器所提供的实体中获得的资源绑定到指定的视图中。

实体O的矩阵为：

其中，N表示实体O可能获取的资源个数；S_i表示实体所请求的资源；P_i表示负责将实体展示到用户界面U_i中的数据提供实体Presenter；i＝1,2,…N。

对于任一对用于将数据展示到用户界面中的数据提供实体Presenter和该数据展示实体对应的用户界面U，对应关系矩阵为：

其中，V_i是用户界面中的视图，F_i是实体O中的成员变量。

与现有技术相比，本发明所具有的有益效果为：本发明提出一种基于Android平台的开发框架，前端工作人员主要负责界面的实现，不需要编写任何代码；后端人员负责编写数据来源代码、实现业务逻辑。此框架可以实现前端数据展示和后端业务逻辑彻底分离，让没有代码能力的前端参与到开发中，减少不必要的重复工作。对于后端人员来说，此框架提供一套前端数据获取流程的抽象，而具体的实现可以由开发者选用合适的第三方框架来实现。同时，作为使用范例，此框架默认使用了第三方类库Volley，ActiveAndroid和UniversalImageLoader来作为具体的实现。没有代码能力的前端人员可以通过GUI控件的拖拽来实现界面的设计同时，通过GUI指定各个控件和服务端中数据的对应关系，实现数据的自动获取和展示。在这一整个过程中，前端人员不需要写任何代码，在运行时，数据可以自动展示在界面中。本发明一方面可以减少代码量，增加代码可靠性；另一方面可以使逻辑结构变得清晰，将数据业务流程和其他逻辑(视图逻辑等)分开，提高代码的可测试性。

附图说明

图1为本发明总统架构图；

图2为本发明资源提供器结构图；

图3为本发明URI图的结构图；

图4为本发明第一类替换原理图；

图5为本发明第二类替换原理图；

图6为本发明Source(资源)，Object(实体)和User Interface(用户接口)三者关系示意图；

图7(a)为实体和用户界面的关系图；图7(b)为符合单一职责原则的Source(资源)，Object(实体)和User Interface(用户接口)三者关系示意图。

具体实施方式

本系统包含了三个主要部分：

1.资源提供器(Resource Provider)，用于负责在全局范围类提供数据

2.虚拟加载器(Virtual Loader)，用于动态加载dex文件中的类或者外部文件中的类

3.视图绑定器(View Binder)，是一个可扩展的类容器，用于将不同类型的数据绑定到对应的控件中

在此框架之下，UI层独立于数据层以及模型层。因此，开发者不需要关心UI层，以及数据是如何展示在UI中。同时，UI开发人员可以独立地开发出合适的用户界面，不需要编写任何代码。系统的总体架构如图1所示。

资源提供器通过职责链模式(Chain of Responsibility)将不同的资源提供器组织起来，任意的资源提供器可以动态地被加入或删除。因此，当虚拟加载器(VirtualLoader)需要进行动态加载的时候便可以很迅速的通过资源提供器获取所需资源，并提供给视图绑定器(View Binder)对该数据进行处理。而且，用户界面层独立于其它层。用户界面可以从本程序中加载，也可以从外部存储中加载。换句话话说，用户界面是在运行时决定的。任何一个数据实体都是面向资源(resources-oriented)的。在此架构之下，应用程序可以在不需要更新全部程序的基础下进行动态升级。

资源提供器的结构如图2所示。资源提供器使用了职责链模式，每个资源提供器都有一个可为空的上级(successor)。当一个资源提供器无法处理某个请求时，它会将这个请求分发到上级，直到任意一个资源提供器处理了这个请求，或者上级为空。当一个实体从资源提供器中取回了数据，资源提供器实际上分别在服务端，本地存储，文件系统以及缓存中进行存储。在用户角度上来看，展示在用户界面中的数据是直接从服务端、本地、文件系统或者缓存中读取的。而从开发者的角度来看，开发过程是面向抽象的(abstract-oriented)，因为资源提供器是独立于业务层的，开发者只需要从资源提供器从获取数据。

资源提供器的工作流程：

1)资源提供器得到所需加载的数据对应的URI

对于每一个资源提供器，都需要一个特定的URI来加载指定的数据。例如，为了可以从服务端中通过HTTP协议接收数据，需要一个符合HTTP协议的URL。因为实体是独立于数据提供器的，因此任何需要接收数据的实体需要制定一个URqI(Uniform RequestIdentifier)。URI mapper会把URqI转换成不同数据提供器所需要的URI。这个过程如图3所示。

2)资源提供器根据对应的URI获取数据

一般来说，数据的获取过程是耗时的操作，特别是当数据从服务端中获取时，数据获取的速度取决于网络带宽以及服务端的响应时间。为了减少用户的等待时间，加载的过程总是在非UI线程中进行。当数据加载完成之后，将会发送一个消息到UI线程队列中，并更新UI。为了增强系统可维护性，本框架提供了异步的接口作为输入，因而数据的加载不需要占用UI线程的时间，提高了用户体验。在此原则下，提出算法：

步骤1)提供统一资源标识符URI、接收UI线程回调的对应接口、资源提供器

步骤2)通过检索资源提供器获得数据对象o

步骤3)判断如果该数据对象o为空，则从资源提供器中获取新的替代资源P

步骤4)如果资源P为空，则该线程处理失败

步骤5)如果资源P不为空，则处理该数据P与UI线程

步骤6)如果数据对象o不为空，则UI线程处理数据对象o

3)实体从资源提供器中取回数据进行使用

对于任意一个资源提供器，都需要处理特定的数据并返回特定的数据类型。对于同样的输入，必然得到相同的输出。因此，对于任何需要经过资源提供器的处理，必须指定一个输出类型。

在Android应用中，有两类最经常使用的基础资源提供器：服务端资源提供器和本地数据库资源提供器。其中服务端资源提供器的来源最经常采用HTTP协议；对于后者而言，采用Android系统内嵌的小型关系型数据库SQLite。

对于用户使用注入器注入的实体，将实体分为三类：请求-响应范式实体(Poster)、数据加载实体(Director)以及数据获取实体(Multiple)。对于这三类实体分别进行具体的实现。这些实体对象会在虚拟加载器(Virtual Loader)加载的交互界面activity调用具体业务所需要的时候，由资源提供器提供出来并使用。

在Android系统中，启动activity的方法由Intent指定目标activity来实现。虚拟加载器的工作流程如下：

1)用户调用本框架重写的方法来启动Activity

虚拟加载器需要根据不同的最小可替换单元MRU动态加载界面activity，因此本框架重写了启动界面activity的方法，提供了接口：

startActivity(Context context,String pkg,String activity)

该接口的参数描述如表1所示：

表1 参数描述表

context	上下文环境
		pkg	目标activity的包名
activity	目标activity的名称

当用户调用了此接口时，虚拟加载器会根据界面(activity)名称中最小可替换单元(MRU)数据库中进行查询，如果本地中存在此MRU，则加载该MRU，否则，执行原有activity。

2)根据不同类别的最小可替换单元(MRU)，分别进行不同的处理

(1)第一类替换

开发者需要某个资源时，例如，用户界面中的某个控件，需要在Java文件中通过该索引系统获得这个资源的引用。因为应用程序不清楚外部的资源，所以使用索引系统会导致资源替换的失效。因此，对于第一类替换，绕过索引系统，使用一个标识符(identifier)来对资源进行重新导向。该过程如图4所示。

由于资源id在不同上下文中对应的控件不同，因此，实现第一类替换的MRU模块必须使用对象名绑定。

在一个界面(Activity)中，虚拟加载器会将资源重新导向到最小可替换单元(MRU)所在的外部存储中。这个MRU包含了用于替换应用程序中原有的布局资源。当应用程序查找此布局文件时，虚拟加载器会重新导向到MRU中的布局，并且通过标识符(identifier)来加载该布局。

(2)第二类替换

对于第二类的替换(Activity替换)，通过类加载器(ClassLoader)来加载外部存储空间中的目标界面(TargetActivity)。如图5所示，当应用程序需要加载一个特定的Activity时，虚拟加载器会在本地数据库中查找是否有相应的MRU。当查找到此MRU时，虚拟加载器会加载一个代理Activity(ProxyActivity)作为代理，并通过ClassLoader来加载MRU中的目标Activity，并把它作为一个普通的，不受ActivityManager管理的类。所有TargetActivity中的生命周期是通过代理界面(ProxyActivity)来实现的。当TargetActivity请求任何资源时，它会实际访问ProxyActivity的资源，并重新定向到外部存储中的资源。

虚拟加载器(Virtual Loader)是连接资源提供器和视图绑定器的桥梁，在虚拟加载器动态加载交互界面(activity)的同时，视图绑定器需要将这个activity所要展示的数据绑定到对应的组件上，这些数据便是通过资源提供器所提供的实体中获取。

数据来源(Source)，实体(Object)和用户界面(User Interface)三者的关系如图6所示。对于每个实体，都有一个或多个数据来源以及用户界面与之相对应。

数据绑定器工作流程：

1)获得实体O、资源提供器P与数据S的对应关系矩阵

把为任意一个实体O希望获取的资源定义为S，并把数据提供实体Presenter(P)定义为负责将成员F绑定到对应用户界面U中对应的视图V。任意一个实体O可以从多个资源S中加载数据，并通过不同的Presenter，展示在不同的视图V中。因此，得到实体O的矩阵：

此处的N表示这个实体O可能获取的资源个数。例如一个联系人的实体既可能是从云端A中获取并展示到界面A，又可以是从云端B中获取并展示到界面B。S_i表示实体所请求的资源。P_i表示负责将实体展示到用户界面Ui中的数据提供实体Presenter.

对于任意一对{P,U}，可以定义矩阵P为

其中，V_i是用户界面中的视图，F_i是实体中的成员变量。

2)检查将要绑定的资源是否符合视图所特定的变量类型

在数据展示实体(Presenter)中，对于任意一个方法所返回的值都被绑定到了注解(annotation)所指定的视图中。该返回值有多种类型，例如数组，字符串，整型，布尔值等；同时视图也可能是文本框，图片框，勾选框，列表等。特定的视图只能支持特定的变量类型。例如，数组类型的变量可以在列表中展示，而布尔变量则不行；而布尔变量可以展示在勾选框中，但是数组变量不行。为了保证特定的变量不被展示到错误的视图中，在视图绑定之前，需要对变量类型进行检查。这个过程如算法所描述：

步骤1)遍历每一个提供器所给出的方法

步骤2)如果该方法M内存在注释A，则得到这个注释的值ID

步骤3)得到方法M的返回值value

步骤4)在用户接口中通过ID找到对应的视图V

步骤5)检查返回值value类型，如果正确则将返回值value赋予给视图V，如不正确则抛出警告

步骤6)继续检查下一个提供器中的方法

3)将实体获得的资源绑定到指定的视图中

资源提供器会把视图绑定器所需使用的数据注入到不同的实体中，在实体获取到资源后，这个实体会展示到用户界面中。为了将资源中特定的成员绑定到指定的视图中，通过注解(annotation)的方式来将实体中的成员变量绑定到用户界面中的特定视图中。在某些情况下，实体同时也是数据展示实体(Presenter)，因此实体和用户界面的关系是一对一的，如图7(a)所示。在其他一些情况下，比如一个实体可能对应多个资源，并需要展示在不同的用户界面中，因此，为了符合单一职责原则(Single Responsibility Principle,SRP)，需要一个Presenter来将实体展示到用户界面中，如7(b)所示。

Claims

1.一种面向嵌入式系统开发的动态数据通用框架，其特征在于，包括：

资源管理器，用于负责在全局范围内提供数据；

2.根据权利要求1所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，所述资源提供器的工作流程包括：

1)获取所需加载数据对应的资源标识符URI；

2)根据对应的URI获取数据；

3.根据权利要求2所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，根据对应的URI获取数据的具体实现过程包括：

2)通过检索资源提供器获得数据对象o；

4.根据权利要求2或3所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，所述实体包括请求-响应范式实体Poster、数据加载实体Director以及数据获取实体Multiple。

5.根据权利要求1所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，所述虚拟加载器的工作流程包括：

6.根据权利要求1所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，所述视图绑定器的工作流程包括：

1)获得用户使用注入器注入的实体O、资源提供器与数据的对应关系矩阵：

2)检查将要绑定的资源是否符合视图所特定的变量类型；

3)将资源提供器所提供的实体O中获得的资源绑定到指定的视图中。

7.根据权利要求6所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，实体O的矩阵为：

O = [\begin{matrix} S_{1}, S_{2}, ..., S_{N} \\ P_{1}, P_{2}, ..., P_{N} \\ U_{1}, U_{2}, ..., U_{N} \end{matrix}];

8.根据权利要求6所述的面向嵌入式系统开发的动态数据通用框架，其特征在于，对于任一对用于将数据展示到用户界面中的数据提供实体Presenter和该数据展示实体对应的用户界面U，对应关系矩阵为：

P = [\begin{matrix} V_{1}, V_{2}, ..., V_{N} \\ F_{1}, F_{2}, ..., F_{N} \end{matrix}];

其中，V_i是用户界面中的视图，F_i是实体O中的成员变量。