3.1.6 用例 6

图37作为用户，希望和朋友们分享参展的乐趣

当用户看到有趣的商品或者遇到有趣的事情时，都希望通过微博分享给自己的朋友。

3.2 系统需求分析

本节主要介绍系统需求，包括第三方服务授权、系统性能要求。

3.2.1 系统界面运行流畅

系统向用户展示展会概况及展品内容百度移动端下拉词技术，需要加载大量图片，系统占用资源较大，因此需要采用缓存、多线程技术绘制用户界面，保证界面的流畅性。

3.2.2 第三方授权

系统引入的第三方服务需要用户授权后才能使用，引入的第三方服务包括百度云个人云存储（PCS）、新浪微博开放服务等，百度云LBS云服务需要应用申请权限，但用户无需授权。

3.3 总结

系统的需求分析是基于用户在展会前、展会中、展会后的活动，进行合理的分析。包括展会前的决策，系统需要提供丰富的媒体信息供用户参考，帮助用户决定是否参展；展会期间，利用近场识别技术方便用户识别展品，利用百度个人云存储服务持久化展品介绍。另外，还发现用户在展会期间有寻找附近餐厅、交换联系方式的需求。

第四章 系统概述设计

本章主要介绍展览导游系统的详细设计，包括前端交互及界面原型、后端模块设计、数据库设计、多线程时序、第三方服务调用以及与服务器的交换流程。

4.1 系统前端设计

4.1.1 交互和原型设计

图 4 1 一级页面交互设计图

该组交互包括系统一级页面的交互和一级页面的隐藏菜单的交互。

在首页上会向用户展示系统所在的城市，并快速展示该城市的展会情况。用户所在位置的展会情况以列表形式展示。对于首屏展示的展会概览信息，相信用户的关注重点是：展会是否开幕、展会名称是什么、展会地点在哪里等。列表可以上下滑动，方便用户浏览更多信息。

交互方面，采用.0以上版本的标准交互组件，Bar的隐藏菜单将授权放在了一级菜单，方便用户更快捷的授权。

图4 2 二级页面交互设计图1

该组交互包含一级页面与二级展品详情页之间的跳转交互。

当用户点击任意一个展会项目时，系统都会跳转到二级展会详情页，详情页采用可滑动的视图，将展会概况、展会图片、热销产品等放入滑动视图中。

本组交互采用4.0标准交互方案，在二级页面，点击返回按钮可以返回首页，系统会销毁该二级页面。

图4 3 二级页面交互设计图2

该组交互包括展会详情二级页面以及该页面内的操作交互。

二级页面采用滑动视图，将展会概况、展会图片、热销产品放入滑动视图中，展会概况为默认视图，向左滑动到展会图片，从展会图片向左滑动到热销产品，向右滑动到展会概况，从热销产品向右滑动到展会图片。

展会概况简单介绍展会相关信息，包括展会标志、展会名称、展馆地址、举办时间、展会简介等，扩展信息包括展会招募单位、展馆电话等。

这组交互使用了.0标准交互组件，左上角的返回按钮可以返回一级视图，左右滑动是系统定义的标准手势。

图4 4瀑布流视图交互设计图

这组交互包含了二级展览详情页滑视下的展览图片的操作交互。

图片展示方式采用时下流行的瀑布流展示，交互友好，单张图片显示较大，方便用户仔细查看，缺点是一屏显示的图片数量有限，下拉到底部后系统会自动加载更多图片，瀑布流交互后面会详细介绍。

这组交互使用了.0标准交互组件，左上角的返回按钮可以返回一级视图，上下滑动是系统定义的标准手势。

图4.5三级页面交互设计图

本组交互包含展品详情二级页面与展品详情三级页面之间的跳转交互。

在二级页面的滑动视图中，在热门产品视图下，点击任意展品项，即可跳转至展品详情三级页面。三级页面采用滑动视图展示展品海报图片，下方区域为展品文字说明。页面下方均匀分布着三个按钮，从左到右依次为“点赞”（给展品打分时使用）、分享给好友等。在更多子列表中，有观看宣传视频的入口。

通过系统内置的近场通信芯片识别展品后，还可激活展品详情的第三级页面。

这组交互使用了.0标准交互组件，左上角的返回按钮可以返回一级视图，上下滑动是系统定义的标准手势。

4.1.2 瀑布布局

瀑布流，又称瀑布流布局。是一种流行的网站页面布局，在视觉上呈现为锯齿状的多列布局。随着页面向下滚动，这种布局会不断加载数据块并追加到当前尾部。最早采用这种布局的网站是，在国内逐渐流行起来。国内大部分新鲜网站基本都是这种风格。

瀑布流有很多优点：

布局比较简单，没有什么特别的难度，不需要明确知道数据块的高度，当数据块中有图片时，也不需要指定图片的高度。

但是缺点也非常明显：

1.列数固定百度移动端下拉词技术，扩展困难。当浏览器窗口大小变化时，只能固定x列。如果要增加一列，很难调整数据块的排列。

2.滚动加载更多数据时，还需要指定插入到哪一列，不够方便。

3.数据块从上到下排列到一定高度后，再将剩余元素按顺序添加到下一列，这个有本质区别。

4.2 系统后端设计

4.2.1 系统模块设计

本系统采用MVC架构，将实体、控件、视图进行分离，这样做的好处是系统架构清晰，模块划分细化，大大降低了各个模块的耦合度，方便系统开发和维护。

下面对系统中MVC架构的使用进行概述。

view层是用户界面，是用户与系统交互的重要层，包括（活动）组件、view（视图）组件、（适配器）三个模块。

 （）组件模块：是视图的容器和捕获用户与系统之间交互的模块。

 视图组件模块：是数据展现的容器，负责向用户展示后台数据，是活动组件的内容。

 （）模块：是一个数据容器，负责组织后台数据。活动组件所显示的数据由适配器提供。

控制层是负责与用户的交互逻辑以及系统与服务器交互的逻辑模块，包括多线程管理、数据库管理、界面三个模块的内容。

 多线程模块：系统实现需要消耗大量的资源，为了保证界面的流畅度和系统执行的效率，资源的加载和渲染采用异步加载。此模块负责与后台交互，获取相关数据并封装。

 数据库模块：该模块用于持久化系统数据，包括第三方授权信息，联系信息等。

 服务模块：系统使用第三方提供的服务，包括百度云服务、新浪服务开放平台等，此模块是基于第三方提供的服务的逻辑封装。

实体层是数据容器模块，系统运行时会维护大量的业务数据，设计此层是为了更有效地管理业务数据。

 业务数据：包括存储在数据库中的第三方授权、联系人、实体类等。

4.3 系统视图层设计

4.3.1 展品列表界面刷新流程

图4 7 展览列表界面刷新流程

系统首次运行时会先定位用户所在位置，会使用百度LBS云服务，云服务器返回位置信息，然后系统以位置为参数从后台查询本地展会列表，若列表为空则提示用户本地没有展会，若有则展示展会列表给用户。

4.3.2 展会概览界面刷新流程

图4 8 展览概览界面刷新流程

当系统从一级页面跳转到二级页面时，系统会先获取用户选择的展会ID，然后以该ID为参数与服务器交互查询展会概况，服务器返回的信息经过逻辑层封装后返回给视图层进行数据显示。

随着用户继续向下滚动瀑布图，展览图片会不断加载，这个过程需要系统再次向服务器请求图片数据。

4.3.3 展品详情界面刷新流程

图4-9 展品详情界面刷新流程

系统首先识别展品的ID，然后以ID作为参数向服务器查询该展品的详细信息并显示给用户。

4.4 总结

系统前端设计采用基于用户体验的交互设计原则，交互组件采用.0以上版本的标准组件；后端采用MVC架构，将逻辑与视图分离，降低系统的耦合度；系统模块细分，去除系统的粒度，方便系统的开发。

第五章 系统详细设计与实现

本章主要描述了系统各个模块的详细设计，包括相关类的依赖关系以及消息传输的时序。

5.1 视图层详细设计与实现

本节将分章节讲解视图层中各个类的职责，并简单描述其设计，最后讲解该类与逻辑层交互的时序逻辑。

5.1.1 展览列表首页详细设计与实现

展会列表首页（一级页面）是指用户打开系统后看到的第一个屏幕。

它的主要职责是向用户展示其所在城市的展览列表，其展示的内容和交互参考第4章的相关内容。

班级名称：

图5.1 展品列表首页（一级页面）刷新顺序

展览列表首页（一级页面）刷新交互顺序如上图所示：

1. 用户打开系统

2. 系统调用方式同步向百度LBS云服务器请求用户位置信息

3.百度云服务器返回信息并封装后返回给系统

4.根据服务器返回值，系统启动多线程，同步向服务器请求本地展示列表

5.服务端返回展会列表信息，逻辑层将这些信息封装成实体类列表，然后调用更新首页UI（用户）

5.1.2 展览详情页详细设计与实现

展会详情页是指用户在展会列表页选择某个展会后，看到的对应展会的详情页面。

其主要功能是向用户展现展会的详细信息，包括文字介绍、图片介绍、热销产品介绍等，相应的交互和视觉设计请参考第四章相关部分。

班级名称：

图5.2 展会详情页（二级页）刷新顺序

展会详情页（二级页）刷新交互顺序如上图所示：

1. 当用户在展会列表页选择展会时，系统跳转至展会详情页

2.系统调用获取用户选择的展会ID

3、系统启用多线程，同步请求服务器返回展会详情。

4.服务端返回详细信息，逻辑层将信息封装成实体类，并调用刷新接口

5.系统支持多线程，异步向服务器请求展会热门展品信息

6.服务器返回热门展品信息，逻辑层将信息封装成实体类列表，并调用刷新接口

5.1.3 展品详情页详细设计与实现

展品详情页是指用户在展会热销产品视图中选择展品后，查看到相应展品的详情页面，或者用户将集成NFC芯片（安装有本系统）的手机靠近摆放在展会中的标识卡，系统识别到该卡片上携带的展品标识信息后，打开的展品详情页面。

其主要功能是向用户展示展品的详细信息，包括文字、图片、视频等，相应的交互和视觉设计请参考第四章相关部分。

班级名称：

图5 第三个展品详情页（三级页面）刷新顺序

展品详情页（三级页面）的刷新交互顺序如上图所示：

1.系统调用获取展品ID信息

2.系统启用多线程，同步向服务器请求展品详情，逻辑层将信息封装成实体类，并调用刷新页面

3、用户打开视频，系统打开自带的视频播放器向服务器请求资源进行播放。

5.2 逻辑层的详细设计与实现

本节将简单说明各个逻辑层类别的职责并简单描述其设计。

5.2.1 联系人模块详细设计与实现

本节主要讲解了联系人模块的详细设计与实现，包括数据库表的设计、联系人模块的使用流程。

表 5.1 联系人数据库表

班级名称：

该类负责联系人管理，功能包括管理用户的个人信息以及通过终端交互的联系人信息，支持插入、删除、修改、查看操作，并负责系统的联系人交互逻辑模块。

下图说明了用户使用系统输入联系信息的流程：

图5.4 系统输入联系人信息流程

用户进入联系人管理界面后，系统会检查系统中是否有默认联系人，若没有则提示用户输入。

下图说明了用户使用系统交换联系信息的过程

图5-5 系统交换联系人信息流程

5.3 关键问题及解决方案

本节将主要介绍系统设计过程中发现的问题及其解决方案，包括瀑布流实现、资源加载任务的设计。

5.3.1 瀑布图的设计与实现

瀑布流是近年来比较流行的一种图片展示方式，相关的介绍在第四章的相关部分提到。但是在移动端实现瀑布流有几个缺陷，这主要是由移动端设备导致的，因为移动端本身处理能力有限，内存小，移动浏览器的解析能力弱，更残酷的是，由于移动端显示屏小，瀑布流在移动端不仅实现难度较大，交互效果也会大打折扣。

不过得益于系统架构的优秀设计，系统并不需要使用HTML语言来实现瀑布流效果，而是可以利用系统本身提供的应用程序框架来解决。

瀑布流的布局是通过动态加载（）来实现的，图片资源等耗时资源的加载带来的巨大系统开销将在下一节解决，本节主要解决瀑布流的布局问题。

瀑布流布局分为三个部分：外部容器，内部容器和内部元素。

外层容器（）：指的是最外层的布局，承载着整个瀑布布局，通过在外层容器上增加内层容器，可以增加瀑布显示的列数，从实现上看，在一个文件中是唯一的。

内部容器（）：指的是内层布局，是外部容器中的元素，承载着瀑布流中的一列瀑布；从实现上来说，是往里添加的，有多少列瀑布就有多少列，也就是在外层布局中添加多个；

内部元素：指图片布局，是内部容器的一个元素，一张图片对应一个内部元素对象，从实现上看，可以是一个布局，也可以是一个复杂的布局，需要添加内部元素才能在界面上显示360搜索手机下拉★64xl.com下拉神器老品牌，搜索框下面推荐的叫什么，内部元素是动态添加到内部容器中的。

这样划分瀑布布局的好处是：

易于管理，可以通过容器对象方便的将元素添加到界面中；

易于扩展。通过全局常量修改内部容器数量，可以增加或减少瀑布流的列数。

实现简单，实现采用提供的标准组件，大大降低了实现难度。

下图表达了三者的依赖关系以及系统的实现；

图 5 6 瀑布流容器设计

红色框框的是外层容器，也就是中间那个；

蓝色线框为内部容器，添加到外部容器中；

绿色线框是内部元素，添加到内部容器中。

下图说明了瀑布流图像的加载过程

图5.7 瀑布流图像加载过程

5.3.2 资源加载任务设计与实现

因为系统会用到多种类型的资源，比如文本、图片等。它们的加载会给系统带来巨大的开销，而使用异步线程来解决资源加载耗时问题则是必然的选择。但是如果针对不同类型的任务设计不同的异步线程，系统结构就会显得复杂，所以在设计时使用了任务的概念。设计任务接口来封装逻辑操作和UI更新操作。不同的资源加载会实现任务接口，封装到不同的任务中。

异步线程会维护任务队列，线程取出任务后会从队列中取出任务并执行，执行完任务后会调用相应接口完成任务。

图5-8 资源加载任务接口与实现关系

接口，要实现此接口必须实现以下接口：

()函数获取该任务与后台交互的URL；

(…) 功能，更新用户界面；

（）函数获取所创建任务的父活动。

,,都是基于接口的实体类，分别处理不同耗时资源加载任务。

5.3.3 异步加载线程设计与实现

在本系统的设计中，为了满足用户获取更多展会或者展品信息的需求，系统会向用户展示大量的富媒体信息，其中包括大量的图片，图片的加载非常耗资源，单线程阻塞加载对用户体验影响很大。

解决方案是使用多线程异步加载，但考虑到瀑布流的实现需要的资源较多，因此会使用两个异步图片加载线程，对于关键资源会使用加锁的方式，让两个线程同步。

对于需要异步加载的图片，系统会将其封装成Task，并将Task放入关键资源中，两个实例会不断轮询获取关键资源并执行，执行完成后会将执行完的任务从关键资源中移除，系统中有两个实例，因此系统可能处于不安全状态。

为了避免使系统处于不安全状态，引用临界区调度原则如下：

1.如果多个进程需要进入空闲临界区，则每次只允许一个进程进入。

2. 任何时候，临界区中不能有多于一个进程。如果一个进程已经进入了它自己的临界区，则所有试图进入临界区的其他进程都必须等待。

3.进入临界区的进程必须在限定的时间内退出，以便其他进程能及时进入自己的临界区。

4、如果进程无法进入自己的临界区，则应该让出CPU，避免进程“忙等待”。

设计中根据临界区调度原则，采用锁定的方式，防止系统处于不安全状态。

当一个线程进入临界区时，锁会被打开，使得其他线程无法进入临界区，线程在临界区内执行从临界资源中获取任务和执行任务的工作，在线程退出临界区前，锁会被关闭，使得其他线程可以进入临界区。

这样的设计不仅有效避免了不安全状态的出现，而且通过这样的设计还可以根据系统负载来添加线程实例，大大提高执行效率。

5.4 总结

为了保证系统平稳运行，设计中很多地方采用了多线程异步处理，使用多线程虽然解决了系统运行效率的问题，但是仍然可能导致不安全的状态，因此在设计过程中针对多线程问题，包括线程操作顺序等做了严谨的设计。

图片的显示采用目前比较流行的瀑布流格式，但加载图片资源会带来巨大的资源开销，影响系统的运行效率。针对这种情况，也有采用多线程、任务的方式来解决。但这种方式会造成死锁问题。为了避免死锁，系统也采用了相应的设计方案。这些都会在本章的各个小节中进行讲解。

第六章总结与展望

6.1 总结

本文在对国家宏观经济运行的观察基础上，抓住经济转型关键节点上最具活力的经济增长点之一——会展经济，并以此为切入点，进行了这一制度的设计和实施。

会展业是朝阳产业、绿色产业，已成为许多一二线城市的支柱产业，但通过研究会展业的现状发现，其在新媒体宣传方面存在着严重的滞后现象。本文结合IT（信息技术）行业目前最热门的两大话题云计算和移动互联网，运用相关知识理论和先进经验，尝试解决这些问题。

本文在认真分析用户需求和展会商业需求的基础上，对系统的功能设计和交互设计做了大量工作，采用流行的交互方式，精心设计系统模块，保证系统高效运行。依托百度提供的强大云能力，借助移动互联网的飞速发展，系统成功落地。

6.2 展望

本系统的实现为解决展会宣传能力落后于展会发展的问题提供了一种可能。但是，本系统目前的实现和设计还存在很大的不足，这也意味着系统还有很大的改进空间。总的来说，包括以下几个方面：

1、对用户需求和商业需求覆盖不够。只注重解决用户问题，无法实现系统对会展行业发展的商业价值。对于系统本身来说，能获得大量用户固然是好事，但更大的意义在于将这些用户的消费进行转化。这是系统在解决基础问题之后亟待思考的问题。

2、关于系统的交互，虽然我们已经尽力以用户体验为出发点，但由于个人能力的限制，设计还不够完善，应该在用户体验上增加更多功能，以获得更多用户的认可。

3、虽然系统用到了百度云的能力，但其实百度还可以提供很多云的能力，比如管道、长连接等，这些能力的使用可以大大提高系统的可用性，无论从用户角度还是商业角度都是很有价值，应该多多利用。

4、由于个人水平有限，系统架构和实现上还有很大的提升空间，希望后续能针对系统运行效率、资源消耗等问题进行改进，提升系统品质。

参考

[1]李阳等.UML与模式应用[M].第3版.北京:机械工业出版社,2006.

[2]李刚.疯狂讲稿[M].第1版.北京:电子工业出版社,2011.

[3]杨凤生.应用程序开发秘诀[M].第1版.北京:2010,机械工业出版社.

[4]作者.用户体验要素[M].原书第2版.北京:机械工业出版社,2011.

[5]   BO。

[6]作者，李li的应用程序开发。

[7作者[M]。

[8] UI：＆[M]。