基于Widget业务解耦引擎的设计与实现

牛安琪，刘绍华

（北京邮电大学电子工程学院 北京 100876）

基于Widget业务解耦引擎的设计与实现

牛安琪，刘绍华

（北京邮电大学电子工程学院 北京 100876）

随着信息化的逐步推进，为了响应国家节能高效的号召，无纸化办公已经在政府机构中得以推广和普及，让人们在能够享受高效便捷的办公体验的同时，又减少了资源的消耗。在面对诸多繁杂业务时，由于对于业务本身缺少理解和规划，在无纸化的过程中存在着诸多的转换中的性能挑战[1]。本文基于Android系统，在设计和实现了一种具有通用性的一套解耦平台，在实现了传统办公功能的同时，有效地降低了展现给用户界面的时间和提高了用户处理业务的速度，为办公的流程提供了简单直接的操作方式，同时也集中体现了软件设计中高内聚低耦合的设计思想，可以使用于同类的业务解耦问题。

Android开发；widget平台；分发引擎；解耦高效

0 引言

随着信息科技的高速发展，特别是网络技术和移动通信技术在全世界的推广，人们获取信息的手段发生了巨大变化，尤其是那些对实现实时信息要求强烈、移动性强的单位和个人，移动计算和无线数据技术将为他们的工作带来崭新的变化[2]。在办公室中，利用一个终端能接收所有的语音、数据来电，而不需要用固定电话、手机等多种接入设备，这是移动办公在企业内部的理想应用，越来月月的需求使得基于功能实现而设计而成的应用软件越来越臃肿，更多的业务耦合在一起，既增加了业务逻辑处理的时间，又降低了用户体验的流畅度，因而一种可以适用于移动办公领域中的解耦分发机制就应运而生，可以直观的让用户看到所有的业务需求入口，同时又降低了用户交互的时间，在达到相同业务处理的同时，有效的节省了用户的时间，提高了办公效率[3]。

本论文实现的业务解耦引擎，是基于 An-droid系统中的Widget组件，将单一的业务流程入口改善为多入口，并且可以直观的放在主屏幕中，这样在降低了操作深度的同时，也能帮助用户快速便捷的进入到操作界面，从而达到了对与复杂业务的解偶目的。其中对于PendingIntent和GridView的研究以及利用了Android系统中的跨进程通信机制，达到了将不同的APP整合集中在本引擎中，方便管理与控制[4,5]。有效的提高了用户操作的效率，节省了操作时间。

1 业务解耦引擎的需求分析

业务解耦引擎是需求驱动的创新，为了解决在已有的生产生活中电子办公效率低的问题而产生的应用型创新，下面将从产品需求，功能性需求以及非功能性需求三个方面来分析[6]。

1.1 产品需求

移动办公是当今高速发展的通信业与 IT业交融的产物[7]，它将通信业在沟通上的便捷、在用户上的规模，与IT业在软件应用上的成熟、在业务内容上的丰富，完美结合到了一起，使之成为了继电脑无纸化办公、互联网远程化办公之后的新一代办公模式。随着国内网络发展的日益成熟，移动办公越来越受到企业的亲睐。

对于企业的领导来说，他们也会需要在出差时随时需要查看、调用、审批内部的资料文档，并知道业务进展及流程进度。这时他们需要移动办公产品来帮助他们不受空间、时间的限制，在任何时候任何地方都能轻松方便地处理手头紧急的工作[8]。

又由于在行业中单一的业务类型少之又少，大多是更具有综合性，业务重叠交叉比较多的应用场景，这时，能够完成用户的业务需求仅仅是基础工作，更多的我们还要着眼于提升用户处理的效率，为用户节省宝贵的时间，这种情形下，一个能够专注于业务分发和管理的引擎就显得尤为重要，通过引擎的中转和分配工作，将一部分原本应该由用户来操作的事件承接过来，完成自动化的处理，不仅体现了电子办公的自动化特性而且切实的便利了用户，获得了更好的用户体验。

因此，这样一种业务引擎的设计和研究，是具有现实的意义，并且能够提高办公的效率的。

1.2 功能性需求

业务引擎核心需要解决的问题就是对不同业务应用的管理和权限分配问题，可以通过以传统应用与解耦引擎应用对比进行分析：

通过上面的表格我们可以知道，Widget引擎由于他特有的平面型多入口特点，使得用户在进行业务选择时候的操作时间有效降低，并通过多入口的登入方式，不再拘泥于单一的业务，可以有效的组合不同方面的业务来达到多样的办公特点[9]。

表1 解耦引擎与传统应用的特性对比Tab.1 Features comparisonbetween decoupling engine and traditional application

主体上依托Widget控件，搭建起了同系统的交互桥梁。

Widget模块：作为直接与用户交互的功能承载，Widget平台是具有对于不同业务的分发和处理的功能，同时，还可以通过这个平台来控制对于不同逻辑入口的权限，实现了不同的用户对应不同的操作权限的功能，有效的降低了对于无效信息的筛选工作，通过进程间的通信，并根据包名就可以确定出对应的具体业务，而Widget完成了对于用户请求初步处理。

用户身份验证模块：作为个性化定制的集中体现，借助于Widget的管理平台，通过持有指定办公的名单列表，可以管理和控制不同的人员的权限问题，从而解决了政府企业文件签批问题中的审批权限问题。

单一业务职能模块：作为与传统应用的强重合点，除了继承完成传统业务需求的前提，这个模块还完成了对于业务的整理分析，并进行解耦抽离的工作，尽量将每一个部分的业务都能单一化处理，避免了在业务逻辑层面的交叉，更为引擎的搭建奠定了业务基础。

1.3 非功能性需求

时间效率方面：通过将不同的业务入口直接放在引擎上与用户交互，这一改变，将用户的操作时间节省了一半以上，用户不再需要通过同一个入口进入选择页面去选择，而是直接从引擎入口就可以选择自己所需办理的业务，表现与交互形式更加快捷和方便。

安全性方面：该引擎现在采用了用户名和密码以及网络传输中的 https协议来保证数据的安全问题，同时平台还具有可拓展的性能，还可以兼容通过证书，SIM卡信息和设备ID信息等来保证用户的唯一性和用户数据的安全性。

稳定性方面：基于引擎的应用可以可以保证500次及以上的操作的流畅度和稳定性，符合了OA系统对于系统的响应需求，并经过了测试实验[10]。

2 引擎整体设计方案

基于Widget的业务解耦引擎，核心是通过安卓系统中的组件作为平台，利用系统本身所拥有的跨进程通信的方式来中转和分发不同的业务流，平台也依托具体的业务流程，进行模块化划分。

2.1 整体结构设计

本文将根据在抽象层分布位置的不同来进行模块的划分，主要分为网络模块、平台整体模块、应用层模块以及单一任务模块的设计，通过模块化的处理，能够将复杂的工程需求按照一定的工程规范进行划分，便于工程管理，功能解耦以及把控工程各部分的性能和进度。如下所示图1是整体架构的设计。

图1 整体架构设计Fig.1 Design of system architecture

通过上图可以知道，整体设计中，将网络模块作为整体引擎的基础支撑，负责移动端和服务器的交通中转，上面是整合模块，作为引擎的核心，会根据一定的指导性文件引导用户进入特定的流程，再上面是应用模块，负责所有应用之间的逻辑关系，并处理扩展性，最上面是对单一应用的设计，结合具体应用完成业务处理。

2.2 分发平台的设计

分发平台的设计，是基于本地的配置文件而建立起来的，如果没有检测到配置文件的存在，将会采用默认的配置文件内容，当平台直接与用户交互时，整合引擎将根据用户的指令，去解析本地存储的配置文件，并将用户的操作转换成配置信息， 再加入本地读取和解析出来的配置文件信息进行重组和打包，之后发送给移动端的系统服务，系统服务持有移动端所有注册了的应用，将服务端接受到平台的申请时，进行进程间的调度，并将申请向下进行分发，指定开启用户需求的应用程序，并完成计算机内部资源的准备和创建工作。

如下图2是用户在交互模式下，平台工作的设计。

2.3 平台逻辑层设计

逻辑层的设计，是基于对用户需求的深刻分析，经过了门户部件的登录之后，就可以进入到相应的日常办公模块、文献查阅模块以及工具类模块，这里存放的是自己定制化的引擎分发入口，可以通过Android中的跨进程通信机制（Binder机制）来分发到不同的进程中去[14-15]，从而能够充分的利用移动端的硬件资源，提高效率的同时，又能最大程度的分配计算机资源，达到了资源最优化的整合目的。

图3是应用之间的逻辑关系图。

图2 交互模式下的平台设计Fig.2 Design of platform in interactive mode

图3 逻辑层应用的总体设计Fig.3 Design of logic layer application

3 业务解耦引擎的实现

根据上面的需求分析和设计，本章将从网络的实现，UI界面的实现和widget平台实现三个关键技术来说明具体的实现过程。

3.1 网络模块的实现

对于网络模块的实现，在分析和综合了各大框架的优势之后，采用了开源框架 okHttp和 RxJava的基于观察者模式的异步处理为基础来封装了里面的网络请求[11]。

为了保证在频繁的网络请求中，能够有序，高效的完成请求过程，并且在整个引擎系统推出时，也能够正确的关闭和释放相应的网络请求资源，从最外层开始采用观察订阅的模式来搭建整体的网络模块。观察者模式，对于处理一步问题，有天然的优势，它并不要求观察者和被观察者处于同一个线程，因此在逻辑上可以灵活的切换线程，而网络请求本身又常常非常耗时，并且返回结果的解析和处理，通常又是一个很耗时的过程，因此，将RxJava应用到网络请求中，十分符合课题的应用场景。

这里封装了POST方式的请求，其中对于各参数进行说明：

RxContext: 该参数是调用方法所在的 activity或者fragment所在的Rx封装类，包括Rx-AppCompatActivity和RxFragment，即是上下文的环境。

URL：网络请求的地址。

Params：网络请求的配置参数。

RXFunc1：OkHttp请求的直接返回结果Response的处理回调类，可以获取成String也可以是inputStream分别应对返回的json或文件流。

影响遗传结构的因素很多，如突变、基因流、选择和遗传漂变，以及繁育系统、进化历史、种子传播机制、习性、物候、演替阶段、分布范围、和环境等。广西地不容主要借助昆虫、鸟、风力等进行花粉传播，造成了居群间相对较大的基因流动（Nm＝1.456 9），阻止了居群间遗传分化的发生。广西地不容的居群较小，居群内的个体数量也较少，基因流可以减轻小居群间近交衰退和遗传变异的减少，对于濒危植物的保护非常有利。但是在某些情况下，基因流会通过远交衰退降低适合度，阻止居群的适应性分化，也会对小居群带来不利的影响。因此，应特别关注基因流在广西地不容居群保护中的作用，一旦发现基因流在世代间的变化较大时要引起注意。

rxSubscriber：结果回调类，用户对于请求的error和成功结果进行处理，对外暴露的接口，可以在这里进行对返回结果的处理。

对于方法的具体实现，是通过 BaseActivity中的一个复合订阅者集合来逐一添加观察者，add方法中的参数是一个 Subscription，他的产生是又 Rx的第三方框架来做，通过产生被观察者Observable，以及配置相应的参数，来获取一个Subscription，如下列出RxJava中重要并且常见的操作：

Observable.OnSubscribe＜T＞：接口，里面的方法Call当订阅者触发subscribe这个方法时候就会执行

subscribeOn(Schedulers.io()) 设置被观察者处于哪一个线程，这里是将观察者切换到IO线程，来保证主线程不做耗时操作。

observeOn(AndroidSchedulers.mainThread())指定 Subscriber所运行在的线程。或者叫做事件消费的线程。这里是切换到主线程即UI线程，方便后续对界面的更新操作。

subscribe(rxSubscriber))将观察者和被观察者进行关联，并触发订阅关系。

每次的网络请求，都会创建一个Call对象，并将配置的参数输入Call对象中并返回，这样就可以拿到每次请求的对象，之后对 Call对象执行 excute方法，并实现其中的接口，来进行获取数据后的操作。

3.2 UI界面的实现

平台依托于AppWidgetProvider组件，其实质是一个广播接收器，在注册时，会有诸多属性：

＜receiver＞中的 name 属性是表明这个组件的具体指向类，值是具体实现类的包名加类名；process属性，是表明这个组件运行于独立的WidgetProcess进程中，目的是为了充分利用计算机的资源，排除在同一进程中与其他组件产生不必要的资源竞争。

对于＜intent-filter＞标签而言，其中的一个属性＜action android:name = android. appwidget. action.APPWIDGET_UPDATE”是必不可少的，因为系统通过这个action标志来识别这个组件为AppWidget组件。其他的一些＜action＞标签，则是具体实现时，自义定的过滤标志，用来识别和启动AppWidget组件。

其中需要特别说明的是＜meta-data＞标签以及属性，name属性，是通常意义的表示作用，而resource属性是为当前标签设计一些资源的文件，可以自定义来实现，从而定制个性化的AppWidget。

以上是对Widget部件在UI界面以及初始化时，进行的一些配置，不同于普通的移动应用，小部件的开发流程有它独特的地方，相应进行设置的地方也需多加注意。

3.3 widget平台实现

以上对于UI界面的展示问题进行了说明，图4是逻辑层中的Widget部件。

在主 Activity的启动过程中，只是仅仅发了一个广播，来启动Widget的生命周期，然后直接结束自己的生命周期。在LoginWidgetProvider中主要用到了Widget的两个生命周期函数onUpdate和onReceive，在onUpdate()中去更新初始化的View，并且网络请求来确定确定各个单一应用的程序接口是否显示[12]。

图4 Widget启动流程图Fig.4 Flow chart of widget

Widget引擎的数据支持与普通的适配器有很多的相同之处，也是由于适配器的实现可以个性化定制，因此才支撑了个性化的Widget的产生。

4 性能测试与实现效果

在完成了对于整体引擎的设计和实现之后，为了检测是否能够正常上线运行、检测是否能够达到用户的要求标准，以及各部分的联合调试，需要在测试环境中进行测试并及时修复问题，以便能够尽可能地改善用户体验。

4.1 测试环境

在内网环境下，应用移动笔记本和移动终端对引擎进行整体的联调的测试，其中软件和硬件的测试环境如下表2，表3所示.

4.2 性能测试

在部署好硬件环境和软件环境，并搭建好内网环境，将程序下载到E人E本上运行，同时通过在程序中注入日志信息的方式得到用户通过引擎处理业务所花费的时间和普通应用通过单一的入口所需要花费的时间。

表2 硬件测试环境Tab.2 Hardware test environment

表3 软件测试环境Tab.3 Software test environment

如上表所示，可知，在 Android系统中[16]，通过传统的方式，要经历两次activity的启动过程，才可以进入到指定的业务中，一次是图标点击进入app，一次是从首页点击再进入业务逻辑页，这里忽略了在首页停留的时间，直接通过startActivity来中转，通过测试可知，平均的耗时在50 ms左右，采用引擎之后，用户在登陆widget之后，只需要一次的点击就可以进入到指定的业务页，从而使得启动时间减少，最后稳定在31 ms左右，可见，引擎的模式具有节省时间的特性，达到了提高效率的目的。

表4 与传统应用耗时对比表Tab.4 Time-consuming comparison with traditional applications

4.3 实际效果测试

在完成性能测试后，进行联合调试，最终的效果图如图5所示。

通过性能测试和结果检测，表明引擎的需求和对节省时间的要求已经达到了用户的需求。

5 结论

本文在深入理解和研究用户的需求基础上，提出的基于Widget的解耦引擎形式，方便了用户处理特性情景下的逻辑，有效的提高了用户操作的效率，节省了时间，对于企业，尤其是事业单位中的多任务，复杂逻辑处理文件过程有很多大的帮助，同时帮助用户对应用进行高内聚低耦合的设计与实现，引擎的研究对于推动无纸办公效率的提高，有一定的推进作用。

图5 引擎首页Fig.5 Login page

[1] 李璐. Avaya 视频云服务首次亮相中国[J]. 通信世界,2015 (33): 31-31.

[2] Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan, W3C Editor's Draft-2013.WebRTC 1.0: Real-time Communication Between Browsers [S], 2013.

[3] K. Egevang. P. Francis. RFC 1631. The IP Network Address Translator (NAT)[S]. USA: IETF. 1994.

[4] 曹珊. 自适应码率控制算法的研究[D]. 内蒙古大学, 2012.

[5] 曲丽君. 基于H.264的视频流式传输技术研究[D]. 中国学位论文全文数据库, 2007.

[6] 樊姗. 基于RTP的H264视频传输技术的研究[D]. 山东大学, 2008.

[7] 屈振华, 李慧云, 张海涛, 龙显军. WebRTC技术初探[J].电信科学, 2012, 28(10): 106-110.

[8] Rosenberg J, RFC5245. Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator (NAT)Traversal for Offer/Answer Protocols[S]. USA: IETF. 2010.

[9] 李蔷. H.264 视频编码码率控制技术研究[D]. 上海: 上海交通大学, 2005.

[10] Rosenberg J, Weinberger J, Huitema C. RFC 3489. STUN -Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)[S]. USA: IETF. 2003.

[11] Petit-Huguenin M. RFC 5928. Traversal Using Relays around NAT (TURN) Resolution Mechanismf[S]. USA: IETF. 2010.

[12] K. Egevang. P. Francis. RFC 1631. The IP Network Address Translator (NAT)[S]. USA: IETF. 1994.

[13] Rosenberg J,Schulzrinne H.RFC3264.An Offer/Answer Model with Session Description Protocol (SDP)[S]. USA: IETF. 2002.

[14] 崔燕南, 薄腾飞. 基于Android客户端的门诊自动分诊导医系统的设计与实现[J]. 软件, 2013, 34(3): 27-30.

[15] 彭鑫, 谭彰, 黄文君, 等. 基于Android的工业控制监控软件设计[J]. 新型工业化, 2012, 2(5): 32-38.

[16] 赵哲, 宋俊德, 鄂海红. 基于Android 平台的移动应用构建研究与设计[J]. 新型工业化, 2013, 3(6): 78-89.

Design and Implementation of Business Decoupling Engine Based on Widget

Niu An-qi, Liu Shao-hua
(School of Electronic Engineering, Beijing University of Post and Telecommunications, Beijing 100876, China)

With the gradual progress of information, in response to the call of national energy efficient, paperless office has been promoted and popularized in government, so that people can enjoy efficient and convenient office experience at the same time, but also reduce the consumption of resources. In the face of many complex business,due to the lack of understanding and planning of the business itself, in the process of paperless there are many conversion challenges in the performance. In this paper, based on the A-ndroid system, in the design and implementation of a common set of decoupling plat-form, in the realization of the traditional office functions at the same time,effectively reduce the time to show the user interface and improve the user processing business sp-eed, For the office process provides a simple and direct mode of operation, but also em-bodies the software design in the high cohesion low coupling design rules and can be used for similar business decoupling problems.

Android development; widget platform; Distribution engine; Decoupling and efficient

TP399

A

10.3969/j.issn.1003-6970.2017.12.030

本文著录格式：牛安琪，刘绍华. 基于Widget业务解耦引擎的设计与实现[J]. 软件，2017，38（12）：160-164

牛安琪(1991-)，男，主要研究方向：计算机移动互联网；刘绍华(1976-)，男，副教授，研究方向：无线通信，嵌入式系统，物联网，云计算，移动互联网。