电子技术论文基于LBS的气象预警Android平台设计
所属栏目:电子技术论文
发布时间:2014-04-21 09:58:41 更新时间:2014-04-21 09:28:41
近几年气象灾害的频繁发生,加大了对气象防灾手段的要求。从气象预警发布手段的角度出发,基于浏览器/服务器模式(B/S)架构的气象预警信息平台被开发与应用[1,2]。伴随着国内互联网的普及与发展,各省、市气象局都加大了对B/S气象预警信息系统的重视与投入。不过从这类系统运行的流程来看,其信息获取主要靠用户主动搜索而来,实施过程中,很容易错过预警信息的第一发布时间,因而难以达到预警的及时通知目的。
摘要:气象灾害预警工作中,时效性至关重要,但是传统的基于B/S架构的气象预警发布系统手段并不能很好地解决这个问题。通过对推送技术的研究,设计了基于Android智能手机,采用第三方推送平台的手机推送解决方案,构建了基于C/S架构模式的实时预警信息推送系统。同时气象灾害预警与地理位置因素密切相关,系统利用移动GIS技术,动态地采集用户的位置,将用户所处区域气象灾害预警提醒推送到用户的手机中,最终以可视化的界面通知用户气象灾害预警的详细信息,实现了气象预警的自动化和智能化。
关键词:气象预警,基于位置的服务(LBS),Android平台
由于Android开放的软件平台和可扩展的用户体验[3,4],近两年Android市场份额不断攀升,加上智能手机的便携性和其计算性能的不断提高,利用Android智能手机实现气象预警将会是一个切实有效的手段。随着移动GIS技术和推送技术的发展,基于地理位置的实时推送技术在不同领域已经有了一些成功的应用和理论研究[5-7]。但笔者在实际应用中发现,由于国内防火墙的原因,国外有些推送服务在国内并不稳定,而一些开源推送的方案目前又不太成熟。综合气象预警的实际情况,本研究采用第三方推送平台提供的推送服务,确定以客户机/服务器(C/S)作为系统架构,利用Android手机定时获取用户所处的地理位置信息,将用户所处位置的灾害情况主动推送到用户的手机端,实现气象灾害预警的自动化和智能化。
1关键问题分析
1.1基于推拉的混合机制
要完成预警信息通知提醒功能,就会涉及到选择推(Push)还是拉(Pull)[8]模型。这两种模型的主要区别在于发起的主体不同,推的主体一般为信息的发起者,拉的主体一般为对信息的请求者。表1为两种模型的具体对比。
通常气象预警信息发布中,预警时间周期具有不确定性和随机性。手机客户端中如果采用拉的方式定时获取预警信息,这种轮回机制难以在时效性和手机端电量和网络流量之间保持平衡。经过分析对比后可以做如下改进:建立自己的气象灾害专用服务器,在专用服务器中定时拉取Web服务器中气象预警信息,同时通过推送代理服务器,由推送代理服务器主动通知客户端灾害预警提醒,这不仅可以解决手机端流量和电量消耗的问题,也可以达到灾害预警时效性强的效果。其基本信息处理时序如图1所示,专用服务器采用拉的模式,定时地从Web服务器中获取气象灾害预警数据,得到数据后,断开连接,并在本地进行处理,判断是否为新的灾害预警,将新的灾害预警城市列表,通过推送接口传递给推送服务器,由推送服务器采用推的模式,将预警提醒主动推送到客户端列表中。此时,客户端会收到一个预警提示,客户端向专用服务器请求具体预警内容,返回到本地手机客户端,最终在本地客户端以可视化的界面显示出预警具体详情。假设专用服务器定时地从Web服务器中拉取预警信息的时间周期为T0,灾害预警发生的时间依次为t0,t1,t2…tn,对于?坌t′,t″∈(t0,t1,t2…tn),且t″>t′,为了保证系统不错过每次最新出现的灾害预警,则必然要满足如下关系,即T0≤min{t|t″>t′|}。因此在气象专用服务器上要尽可能地将拉取周期的时间间隔设置得短一些,以满足上述关系。
1.2推送技术方案
为实现实时推送,选择推送的方案必须要考虑如下几点:第一,实时性好;第二,长连接的机制能够保证手机端流量和电量消耗较少;第三,客户端如果掉线,最好能够有自动重连的机制。就目前来看,为方便开发者推送服务的接入,各大移动操作系统平台都集成了自己的一套推送服务接口。例如苹果的APNS、微软的MPNS以及谷歌的C2DM。然而就Android平台实际使用情况来看,国内使用谷歌的C2DM服务并不稳定,因此,为稳定地实现气象预警灾害推送,C2DM方案并不可行。另一个在Android平台下实现推送服务的方案是采用开源工程Androidpn,是基于XMPP协议实现的,其协议复杂冗余,没有针对手机应用做必要的优化和改造,使用费电,耗流量。经过调查发现,由国内个信互动网络科技有限公司开发的推送服务可靠且相对稳定,电量与流量消耗也相对较少,其掉线重连的机制也使得在线长连接得到了有效保障。Android应用程序开发者提供了一系列基于Android平台的应用程序接口,整个体系架构简单,简化了推送的开发成本,为搭建自己的推送平台提供了一个快速的通道。因而本研究使用由该平台提供的推送服务,其特点是支持文件加密透传,开发者可以对透传信息进行加密,从而不必担心信息的泄漏。
2系统整体结构
系统采用C/S的架构可以充分利用服务端和客户端硬件的优势,将繁重的计算任务交给服务端完成[9,10],减少客户端的计算负载,整个系统结构如图2所示。
1)专用服务器。气象专用服务器用于分析处理气象灾害预警信息,将需要预警的用户列表,通过推送服务器提供的WebService,将处在灾害预警位置的客户端列表发送给推送服务器。同时,专用服务器需要一个网络IP地址和端口号,用于与客户端的通信,包括获取用户位置信息、传递具体灾害预警信息等。
2)客户端。基于Android平台设计的客户端,利用Android手机提供的网络定位功能和GPS定位服务定时地获取用户所处的地理位置,以捕捉变化的用户位置信息,并将变化后的用户位置提交给专用服务器,以便第一时间让所处变化后的区域的用户能够接收到该地的气象灾害预警提醒。应用的关键是用户必须在Android系统设置选项里启用定位服务,包括GPS定位和网络定位服务,否则无法实现与用户位置有关的灾害预警提醒推送。客户端采用推送服务提供的Android客户端SDK,负责推送服务器的长连接通信,并利用该平台提供的推送接口负责接收推送服务器推送过来的信息推送提醒。3)推送服务器。直接实现推送信息的载体,能够在高并发连接的情况下与客户端保持持久的通信,向外围提供WebService接口,接收专用服务器传递的推送客户端列表,并最终将信息推送至传递过来的客户端列表中。
4)Web服务器。气象灾害预警信息的来源,由第三方气象公共服务系统提供,采用格式化的XML数据,采用HTTP的通信方式为用户提供气象灾害预警信息。
5)数据库。系统采用Oracle数据库。数据库与气象专用服务器相连,在系统运行时动态地更新数据库信息。
3系统设计
系统设计主要包括两方面的功能,即灾害预警到来时客户端的及时信息提醒功能和可视化的预警详情查看功能。图3为整个系统的框架模块设计,具体包括两个方面,即气象专用服务器设计和Android客户端设计。
服务器端与外围的信息交互是双向的,抛开整个服务器的内部构建来看,实际上是一个输入-处理-输出的系统处理机制。根据气象专用服务器的功能特点,服务器端架构采用分层的软件设计思想以提高软件未来的扩展性能。软件架构包括3个层次:通信层相当于输入和输出的一个接口,所有数据的传递和交换必须由通信层来解决,包括气象预警资料的获取,与推送服务器的交互以及和客户端用户之间的信息交互。服务层是服务器端工作的核心组件,为实时预警推送和用户信息管理提供支持。为满足气象灾害预警实时性要求高的需求,该层设计了气象灾害监控服务,实时监控气象灾害预警信息的变化。系统服务器端采用Oracle作为数据库系统的业务数据支持,提供了3种数据内容,即历史数据、实时预警信息数据和用户基本信息数据。
Android客户端采用MVC的设计理念,相对应的3个模式为视图显示模式、事件控制模块和业务数据处理。用户在使用本系统软件时,应有一个方便简单的入口,客户端的视图显示用以解决用户和系统交互的问题,是系统使用的功能导航,拥有3个用例,包括系统设置、预警提示和预警查看。事件控制模块负责分发和处理相应的业务数据请求,并将结果显示在视图上,是业务数据处理和视图显示的一座桥梁,在Android系统中主要由Activity完成。业务数据处理模块是MVC3层架构中的数据模型,是客户端数据处理的核心组件。
4关键技术的实现与分析
4.1基于位置的信息采集
Android客户端提供了两种不同的定位方式:网络定位和GPS定位。用户的位置通常是动态变化的,但变化范围绝大部分又限于一定区域之内,如果在一个小的区域范围之内变化,可以视为没有发生位置改变,对于气象预警的结果没有什么影响。本系统中以一个行政规划区(以市级单位为例)为地理变化单位。为方便将地理的经纬度转换为相应的地理位置信息,Android手机端采用百度定位SDK。为使服务器知道用户最新地理位置信息,笔者采取了如下的解决方案:首先由用户通过系统设置选项,设置好定位时间间隔,并保存到系统参数的配置文件中;其次开启Android后台服务(Service),在主线程中注册百度定位监听,并读取系统参数配置文件,设置好定位时间间隔;最后通过百度地理定位监听方法onReceiveLocation(BDLocationlocation),获取用户当前地理位置信息LocUpdate,同时把本次地理位置信息更新到本地数据库中,从数据库中读取用户上一个地理位置区域LocPrevious,并做两次位置对比,如果位置不同,则启用位置更新方法LocNotifyServer(StringLocUpdate),将用户最新位置信息通知给服务器。
4.2预警信息推送
在系统运行中,气象专用服务器要定时地从Web服务器端拉取气象灾害预警信息数据并做处理,将最新的预警数据存到实时预警信息数据表中,同时将历史气象预警信息插入到历史数据表中,因而实时预警信息表中的内容是动态变化的。鉴于气象灾害预警的及时性要求,本系统的预警信息推送采用了两种机制保证信息的及时性:实时预警信息监控机制和实时推送服务。每次服务器端气象数据获取模块拉取的气象预警数据要与上一次的预警数据进行对比,并将最新的预警数据存到实时预警表中,同时将过期的气象预警信息删掉,以保证实时预警表中的数据都是最新的预警数据。这样实时预警信息表中的数据都有一定的生命周期,而其生命周期就是定时拉取Web服务端的时间间隔,设为T0。监控模块要开启定时器定时地扫描实时预警信息表中的数据,检查是否存在最新预警信息。由于不能重复向用户发送预警信息,也不能让用户错过预警信息,定时器的选择要与实时预警数据的生命周期(T0)一致。其处理流程如图4所示。
4.3可视化气象灾害预警显示
手机端结合百度地图以可视化的方式为用户提供灾害预警的查看方式。本地出现气象灾害时,会在手机端通知栏出现灾害预警提醒标志,当用户点击预警标题时,就会跳转到气象灾害预警页面,如图5所示。
1)Android异步线程实现。当用户启动一个页面时,系统会分配一个默认的主线程给相应的页面,但是要获取实时预警信息,实现与气象专用服务器端信息的交互,应避免直接在主线程中实现网络数据下载,否则可能导致主线程堵塞,影响用户的使用体验。因此,该模块中采用了基于Android平台异步线程的设计方案,当启动主线程后,开启一个实时预警信息下载线程,下载完数据后,利用Android提供的线程间传递信息机制,在该线程中向主线程发送通知,由主线程将下载完的数据显示到页面上。
2)用户图层位置显示。为了给用户一个良好的用户交互界面,方便用户预警的定位以及查看周边的情况,系统采用了百度地图实现和用户的交互。系统主要利用百度地图提供的MapView、MapController接口实现地图的显示和地图的操作。通过实现BDLocationListener接口中onReceiveLocation(BDLocationlocation)方法以获得用户精准的地理位置定位,同时自定义自己的图层类,通过继承百度地图ItemizedOverlay类,重写其中的draw方法,以圆形阴影区域显示用户周边情况,最终通过MapView将自定义的图层叠加到底图上,从而实现更加丰富的图层显示。4.4流量分析
气象预警信息资料处理的时效性和基于手机端的流量控制是本系统应用的特色。以1d的全国各地气象预警信息发布为例,从内容和数目上看,多则数十条的气象预警发布条目,少则仅有几条甚至没有气象预警的发布;从发布频率上看,也是难以估计的,这与气候、季节和地域密切相关,其结果存在着随机性。在同等条件下,服务器端轮询拉取气象预警信息和客户端轮询拉取Web气象预警信息频率一样的情况下,采用推拉混合机制模式对客户端流量控制要明显优于单一的手机端轮询机制,图6为在轮询周期间隔为0.5h,流量监控采样周期为1.0h的情况下两者流量对比分析。从图6中可以看出,混合机制对手机的流量控制要优于手机端轮询机制,而且在同时提高轮询频率、增加预警时效性的情况下,混合机制的流量控制优势更加明显。试验结果受网络环境和Web气象预警发布的频率制约,通常情况下网络环境不好时流量消耗会略微提高。
5结语
本系统以Android手机终端作为预警信息传播媒介,初步实现了基于用户地理位置的预警信息推送,用户不再需要自己去手动获取预警信息,而是由服务器端实时地根据用户所处的地理位置实现智能化的预警信息推送。系统的研究工作虽然是在气象预警背景下提出与实施的,但是对于其他行业,例如城市交通管理、农业气象灾害预报等都具有一定的参考价值与意义。
参考文献:
[1]易烈刚,陈官清,张强宜.基于B/S模式的气象预警信息发布平台设计[J].贵州气象,2009,33(5):32-33.
[2]王赟,段燕楠,姚愚,等.气象预警信息综合发布平台的设计与实现[J].成都信息工程学院学报,2011,26(6):656-662.
[3]孙晓宇.Android手机界面管理系统的设计与实现[D].北京:北京邮电大学,2009.
[4]公磊,周聪.基于Android的移动终端应用程序开发与研究[J].计算机与现代化,2008(8):85-89.
[5]何文华.基于地理位置及时信息推送服务分析及Shopylife的设计与实现[D].成都:电子科技大学,2012.
[6]王翔,李庆华,张峰军.基于LBS的智能推送技术研究[J].通信技术,2011,44(12):95-97.
[7]曹海兵,夏英.Push型LBS应用的实现技术研究[J].计算机应用研究,2006(10):232-233.
[8]李志飞,万麟瑞,胡宏,等.WAP应用中的PUSH/PULL集成机制研究[J].小型微型计算机系统,2001,22(10):1178-1181.
月期刊平台服务过的文章录用时间为1-3个月,依据20年经验,经月期刊专家预审通过后的文章,投稿通过率100%以上!