基于LBS的跑步软件设计

肖远东

（福建师范大学软件学院，福建福州350108）

基于LBS的跑步软件设计

肖远东

（福建师范大学软件学院，福建福州350108）

以LBS为基础，根据实际项目需求，利用J2EE相关技术搭建服务器，并基于iOS操作系统设计了一款集跑步和社交应用于一体的跑步软件，实现了以移动终端为前台，以Web架构为后台服务的典型移动应用。根据实际测试结果提出了改进方案。该应用程序的系统架构、测试优化，对于移动APP的开发具有一定的参考价值。

LBS；跑步软件；移动应用；开发架构

0 引言

随着3G网络的快速发展，移动位置服务（Location Based Service，LBS）有望成为3G时代的核心业务之一［1］。LBS促使移动互联网再次进化，移动互联网的普及带来的广大用户群体，给LBS领域带来了巨大的商机［2］。本文设计的目标是开发出一套跑步软件，该系列中不同版本软件既独立运行又进行数据共享。本文设计的软件系列中的主要产品是酷跑主版本软件（以下简称：“主版本”），开发完成主版本之后根据特定的组织机构定制不同版本，如针对院校定制院校版本，针对赛事组织定制竞赛版等。

本跑步软件提供的服务是一种LBS，通过用户手机或者其他移动设备采集用户位置信息，再上传用户位置信息给服务器以获得增值服务。软件中也集成了社区互动功能，给同样有跑步兴趣的用户提供交流平台和比赛平台，提高用户忠诚度［3］。软件的核心目标是为用户跑步服务，但是除了跑步之外可以提供额外服务，比如：用户使用软件即可在地图上获得好友当前位置和行进路线；团队活动不易控制，而同样通过地图，即可获得团队所有人的位置和动向。本课题中开发的软件分为移动终端和服务器，移动终端搭建于iOS平台。

1 系统设计

本系统采用经典B∕S与C∕S结合的架构方式，搭建Web服务器并提供Web页面，同时用户也可使用iOS智能操作系统终端安装软件进行服务的使用。该设计服务器搭建于Linux平台，采用Tomcat作为Web服务器，选择体积小、速度快、总体拥有成本低的关系型数据库MySQL作为数据库管理系统［4］。本系统中客户端与服务器采用的通信协议是HTTP协议，采用的数据交换格式为JSON格式。典型的通信请求如下：

http：//IP：8080∕project∕getList.do？application=xxxxxx&userId=123；典型的数据交换格式如下：

｛“size”：3，“list”：［｛“id”：2，“name”：“张三”｝，｛“id”：3，“name”：“李四”｝，｛“id”：4，“name”：“王五”｝］｝。

1.1 数据库设计

本系统数据库主要包含点评记录、实时路线记录、路线记录、收藏记录、人员、人员关系、评论记录、消息等数据表。各数据表之间的关系见图1。

图1 数据表关系图Fig.1 Relational graph of data table

1.2 服务器设计

服务器采用的架构为Struts+Spring的Web应用程序开源集成框架。Struts1是第一款真正采用MVC结构架构的Web框架，采用Struts能有效减少运用MVC设计模型来开发Web应用的时间［5］。Spring是开源框架，能有效支持项目业务层。本项目中使用Spring的容器技术、事务管理技术等对业务层提供支持，简化业务逻辑处理，加快开发进度。服务器主要分为：用户管理、路线管理、关系管理3个模块。用户管理主要负责处理注册、登录等用户相关操作；路线管理对用户的跑步路线进行存储、排行等业务逻辑的处理；关系管理则负责用户间的关系和社交功能。

1.2.1 用户管理模块用户管理中最主要是登录功能，它将验证用户的登录名和密码是否正确。典型系统输入如下：

http：//IP：8080∕project∕login.do？application=xxxxxx&password=******&name=liu@126.com；

其中application标识应用程序号，password标识用户密码（不可为空），name标识用户登录名，它可以是手机号或邮箱地址。该输入将通过Struts框架送入login.action，系统将访问数据库获取数据并验证登录名和密码是否正确。业务逻辑结束后，服务器将返回JSON格式的数据，如表1所示。

表1 登录接口服务器返回数据Tab.1Return data of server for login interface

1.2.2路线管理模块该模块负责路线上传、历史路线查询、路线排行的业务逻辑处理。路线上传分为两类：①上传一条完整路线，此时前台没有路线ID，参数中路线ID置为-1，参数中需要携带完整路线的GPS坐标；②终结一条实时上传的路线，此时前台有路线ID值（实时上传时后台返回的路线ID），参数中的路线ID必须有效。coordinates可以为空，也可以有最后一段还未上传的实时路线GPS坐标集（该部分如果不为空会当做实时路线的一部分添加到路线中）。典型的系统输入如下（routeId标识路线ID，coordinates存储坐标集合，length代表路线长度，timespan代表耗时）：

http：//IP：8080∕project∕upload.do？application=xxxxxx&id=123&routeId=30&length=2333.45×pan= 234.12&start Time=2011-11-4 10：20：35&stopTime=2011-11-4 12：30：23¤tTime=2011-12-1 12：23：34&coordinates=32.125426，78.569586；

服务器将返回status标识上传结果（成功或失败）。

1.2.3 关系管理模块该模块主要处理好友关系、排行榜等用户之间的各类关系。人员关系将存储在对应数据库表中，系统将依据该表中与用户相关的关系和状态信息，列出用户好友列表。此外，排行榜功能可以依据里程数、速度等信息进行排序，而筛选时间单位也可以是年、月、日。典型的系统输入如下：

http：//IP：8080∕project∕heros.do？application=xxxxxx&id=123&code=1100000&sortType=2&timeType= 2&size=20；

其中application标识应用程序号，id标识用户的人员ID，code标识地区代码，sortType标识排序类型，timeType标识时间筛选类型，size则标识请求排行数，默认为前20。

1.3 客户端设计

本系统客户端基于iOS操作系统设计并实现，系统架构见图2。客户端软件主要分为UI模块、业务逻辑处理模块、网络数据模块。网络数据模块使用NSStream类处理与服务器之间的数据交互；业务逻辑处理模块则用于完成用户间关系、路线管理、个人资料、消息等复杂业务的处理，涉及数据交互的业务将调用网络数据模块；UI模块提供用户操作界面并响应用户选择，将用户操作命令下发至业务逻辑模块处理。

图2 客户端软件架构Fig.2 Software architecture of client

客户端主要功能有酷跑、英雄榜、跑友、路线。酷跑页面是用户跑步时的实时跑步数据和地图路线显示（见图3）。英雄榜页面显示用户和好友跑步成绩的排行榜，用户可以根据地区、里程数等信息进行筛选排序（见图4）。跑友页面显示用户查看跑友跑步情况，是交友、互动交流平台。用户可以根据ID搜索跑友，或者查询附近的跑友，还可以添加系统推荐的相关跑友，还可以根据通讯录添加已注册的朋友作为跑友（见图5）。路线页面则显示平台上跑友分享和推荐的路线，用户可进行点评和启动该路线进行点评。

图3 酷跑页面Fig.3 Running page

图4 英雄榜页面Fig.4 Heroes page

图5 跑友页面Fig.5 Friends page

2 架构优化

2.1 列表请求优化

2.1.1 列表请求系统问题在本项目客户端中有许多列表请求，如跑友列表、路线列表等。列表生成需要消耗较多性能，因为它通常需要对较多数据进行综合统计、归类和排序等操作，同时数据还可能附带图片。大部分系统对于列表的处理采用以下方式：服务器完成列表处理并将它交给客户端，客户端在显示列表的同时对所需的图片进行并发请求。此方法导致服务器压力集中，容易造成阻塞。服务器在列表生成后，需要立即处理图片请求，虽然图片请求不耗费计算性能，但图片传输耗时较长，且需磁盘高I∕O，在服务器繁忙状态下很可能对其他用户请求的响应产生影响。因此，此类请求是性能消耗高的请求，需对此进行优化。

2.1.2 列表请求优化方法以用户信息和头像图标为例，常规做法如图6所示：将用户基本信息以及图片存储于同一数据库表中。该方法存在的最大问题如下：用户信息一般只有几百字节，而头像图片则在10kB以上，因此，经常查询的用户基本信息会“淹没”在头像数据中，导致查询速度降低。

另一种方法是将用户基本信息和头像分开保存，它可以加快用户基本信息的查询，虽然提高了查询信息速度，但出现新的问题：请求列表和请求图片使用同一数据库连接池，图片I∕O会占用较多数据库连接和较长时间。

图6 信息保存在同数据库同表中Fig.6 Information stored in the same table and the same database

图7中的设计将核心服务和图片服务部署在两台不同服务器上。就列表请求和图片请求两种请求而言，列表请求是核心业务，而图片请求是为了增强用户体验，所以应优先满足核心业务，将图片请求的压力集中到图片服务器。此外，还可以根据用户请求量调整图片服务器数量。此设计有利于在系统较为繁忙的情况下，核心服务器及时响应生成列表，尽管客户端的图片显示较慢，但能及时生成列表。

图7 核心服务和图片服务部署在两台不同服务器Fig.7 Core services and photo services deployed on two different servers

采用该设计方式，对服务器而言，只需增加一台图片服务器，不会增加开发工作量；对客户端而言，只需区分核心服务器和图片服务器的地址，不造成客户端压力，不影响流量；考虑收益，此方案利于长远考虑，当用户数增加时，可根据压力分析增加服务器数量来快速提升响应速度。

2.2 压缩合并连接

2.2.1 压缩合并连接系统问题在本设计中客户端需要与服务器大量进行交互，服务器同一时刻能响应的连接数有限，若连接过多会导致服务器连接阻塞或者响应时间较长。若能在不影响业务的情况下有效减少客户端和服务器的连接数，就能有效增加服务器的吞吐量。

2.2.2 压缩合并连接优化方法本设计中的“多人同跑”功能中有两个频繁请求：一是上传用户当前坐标连接，二是下载其他同跑者坐标连接。在同跑开始后，这两类连接以相同频率进行请求才能发挥较好效果，因为上传频率大于下载频率或者下载频率大于上传频率都会降低效率，做无用请求。假定上传和下载的周期定为3 s，同时1 000人进行同跑，那么在3 s内会有1 000个上传连接和1 000个下载连接，服务器需要承受2 000个连接。

假设上传连接为：http：//IP∕project∕upload.do？userId=23&coordinate=26.026013，119.211788；客户端响应为：｛“status”：0｝；下载连接为：http：//IP∕project∕download.do？userId=23&teamId=23；服务器响应为：｛“size”：2，“list”：［｛“userId”：1，“userName”：“张三”，“coordinate”：“26.026014，119.211788”｝，｛“userId”：2，“userName”：“李四”，30“coordinate”：“26.026012，119.211789”｝］｝。

在1 000人同跑时服务器收到1 000个上传数据和1 000个下载数据请求，并分别做出响应。若将上传连接和下载连接压缩合并为同一个连接，将上传和下载的请求定义为：http：//IP∕project∕upload⁃AndDownload.do？userId=23&teamId=23&coordinate=26.026013，119.211788，服务器响应为：｛“status”：0，“size”：2，“list”：［｛“userId”：1，“userName”：“张三”，“coordinate”：“26.026014，119.211788”｝，｛“userId”：2，“userName”：“李四”，“coordinate”：“26.026012，119.211789”｝］｝。

采用此设计方式之后，在3 s内只会有1 000个连接，服务器只需承受1 000个连接。由此可以看出采用合并连接之后服务器的连接数减少了50%，虽然没有减少数据流量和后台工作量，但是减少了服务器的连接数，增强了其吞吐量。

3 测试

3.1 测试环境

测试工具：LoadRunner；服务器操作系统：Linux；Web服务器：Tomcat 6.0.30；数据库服务器：MySQL 5.1。

3.2 测试目的及方法

使用LoadRunner脚本模拟5 000个并发对Tomcat服务器的多人同跑接口持续进行并发访问（上传坐标和下载同跑者坐标），同时采用LoadRunner对服务器响应时间、并发数、CPU状态、内存状态、磁盘I∕O状态进行监测。

3.3 测试结果及分析

图8为系统接口响应时间与测试时间关系图。图9为当前系统存在的并发数与测试时间关系图。

从图8中可以看出在并发运行时，系统的响应时间突增，响应时间升至0.001 8 s，此时，从图9可以分析出此时的并发数大约为4 200。如图8所示，在响应时间增大后，系统再次分配计算机资源以及进行负载平衡处理，在7.5 min左右，系统的响应时间降至0.000 2 s。

图8 多人同跑接口响应时间与测试时间关系图Fig.8 Relationship of response time and elapsed time for multi person running simultaneously

图9 连接数量与测试时间关系图Fig.9 Relationship of session number and elapsed time

3.4 瓶颈分析

根据CPU、磁盘与时间数据分析得知CPU的利用率非常低，不造成系统瓶颈。但CPU Wait较大，即CPU等待时间较长，造成相应事务响应时间较长。磁盘I∕O占用率在虚拟用户数达到5 000左右时突增。而同时期MemoryFree的占有率持续在87.5%以上，5 000用户并发操作时网络I∕O不高，因此判定Memory和网络I∕O也不是造成系统瓶颈的原因，从磁盘I∕O率数据反应并发压力主要集中在Tomcat和数据库部署磁盘中。因此，造成瓶颈的主要问题是：多人同跑接口频繁操作数据库。

4 结语

本文首先介绍了LBS的发展现状，根据项目需求，设计并实现了基于LBS的跑步APP和Web服务器。同时，根据系统架构，分析项目中所存在的问题并提出改进方案。最后，以接口测试为主，通过测试发现接口和系统的瓶颈。本系统支持大数量客户端同时使用，具有响应速度快、资源消耗少等特点，能够为实际活动使用提供很好的支持。

（References）

［1］何永江.3G时代中国联通LBS业务发展模式探讨［J］.信息通信技术，2011（2）：12-15.

［2］WANG X L，PANG X，LUO Y W.LBS-p：A LBS platform supporting online map services［C］//Proceeding of the 72ndIEEE vehicular technology conference，VTC Fall 2010，Semptember 6-9，2010，Ottawa，Canada，2010：1-5.

［3］王文韬，谢阳群.LBS与社交网络联合应用的新模式研究［J］.中国市场，2011（36）：85-86，93.

［4］风尘叹.MySQL［EB∕OL］.（2012-03-12）.http：//baike.baidu.com∕view∕24816.htm.

［5］张春永，陈群.一种基于LBS的移动个性化推荐系统［J］.科学技术与工程，2011，11（30）：7439-7442，7447.

（责任编辑：曾婷）

Design of a Running Software Based on LBS

XIAO Yuandong
（School of Software，Fujian Normal University，Fuzhou 350108，Fujian，China）

Based on LBS，in accordance with requirement of real project，uses J2EE relevant tech⁃nology to construct the server,and designs the running software integrated running into social inter⁃course based on iOS operation system.Realizes the typical mobile application with mobile terminal as proscenium and Web architecture as background server.Proposes the improved scheme according to real test results.The system architecture and test optimization of the application program have ref⁃erence to the development of mobile APP.

LBS；running software；mobile application；development architecture

TP393

A

1673-0143（2014）04-0045-07

2014-03-30

肖远东（1989—），男，硕士生，研究方向：移动平台与嵌入式系统。