基于LBS的氣象預(yù)警Android平臺設(shè)計(jì)

摘要：氣象災(zāi)害預(yù)警工作中，時效性至關(guān)重要，但是傳統(tǒng)的基于B/S架構(gòu)的氣象預(yù)警發(fā)布系統(tǒng)手段并不能很好地解決這個問題。通過對推送技術(shù)的研究，設(shè)計(jì)了基于Android智能手機(jī)，采用第三方推送平臺的手機(jī)推送解決方案，構(gòu)建了基于C/S架構(gòu)模式的實(shí)時預(yù)警信息推送系統(tǒng)。同時氣象災(zāi)害預(yù)警與地理位置因素密切相關(guān)，系統(tǒng)利用移動GIS技術(shù)，動態(tài)地采集用戶的位置，將用戶所處區(qū)域氣象災(zāi)害預(yù)警提醒推送到用戶的手機(jī)中，最終以可視化的界面通知用戶氣象災(zāi)害預(yù)警的詳細(xì)信息，實(shí)現(xiàn)了氣象預(yù)警的自動化和智能化。

關(guān)鍵詞：氣象預(yù)警；基于位置的服務(wù)（LBS）；Android平臺

中圖分類號：S421；TP302.1 文獻(xiàn)標(biāo)識碼：A 文章編號：0439-8114（2013）24-6161-05

近幾年氣象災(zāi)害的頻繁發(fā)生，加大了對氣象防災(zāi)手段的要求。從氣象預(yù)警發(fā)布手段的角度出發(fā)，基于瀏覽器/服務(wù)器模式（B/S）架構(gòu)的氣象預(yù)警信息平臺被開發(fā)與應(yīng)用[1，2]。伴隨著國內(nèi)互聯(lián)網(wǎng)的普及與發(fā)展，各省、市氣象局都加大了對B/S氣象預(yù)警信息系統(tǒng)的重視與投入。不過從這類系統(tǒng)運(yùn)行的流程來看，其信息獲取主要靠用戶主動搜索而來，實(shí)施過程中，很容易錯過預(yù)警信息的第一發(fā)布時間，因而難以達(dá)到預(yù)警的及時通知目的。

由于Android開放的軟件平臺和可擴(kuò)展的用戶體驗(yàn)[3，4]，近兩年Android市場份額不斷攀升，加上智能手機(jī)的便攜性和其計(jì)算性能的不斷提高，利用Android智能手機(jī)實(shí)現(xiàn)氣象預(yù)警將會是一個切實(shí)有效的手段。隨著移動GIS技術(shù)和推送技術(shù)的發(fā)展，基于地理位置的實(shí)時推送技術(shù)在不同領(lǐng)域已經(jīng)有了一些成功的應(yīng)用和理論研究[5-7]。但筆者在實(shí)際應(yīng)用中發(fā)現(xiàn)，由于國內(nèi)防火墻的原因，國外有些推送服務(wù)在國內(nèi)并不穩(wěn)定，而一些開源推送的方案目前又不太成熟。綜合氣象預(yù)警的實(shí)際情況，本研究采用第三方推送平臺提供的推送服務(wù)，確定以客戶機(jī)/服務(wù)器（C/S）作為系統(tǒng)架構(gòu)，利用Android手機(jī)定時獲取用戶所處的地理位置信息，將用戶所處位置的災(zāi)害情況主動推送到用戶的手機(jī)端，實(shí)現(xiàn)氣象災(zāi)害預(yù)警的自動化和智能化。

1 關(guān)鍵問題分析

1.1 基于推拉的混合機(jī)制

要完成預(yù)警信息通知提醒功能，就會涉及到選擇推（Push）還是拉（Pull）[8]模型。這兩種模型的主要區(qū)別在于發(fā)起的主體不同，推的主體一般為信息的發(fā)起者，拉的主體一般為對信息的請求者。表1為兩種模型的具體對比。

通常氣象預(yù)警信息發(fā)布中，預(yù)警時間周期具有不確定性和隨機(jī)性。手機(jī)客戶端中如果采用拉的方式定時獲取預(yù)警信息，這種輪回機(jī)制難以在時效性和手機(jī)端電量和網(wǎng)絡(luò)流量之間保持平衡。經(jīng)過分析對比后可以做如下改進(jìn)：建立自己的氣象災(zāi)害專用服務(wù)器，在專用服務(wù)器中定時拉取Web服務(wù)器中氣象預(yù)警信息，同時通過推送代理服務(wù)器，由推送代理服務(wù)器主動通知客戶端災(zāi)害預(yù)警提醒，這不僅可以解決手機(jī)端流量和電量消耗的問題，也可以達(dá)到災(zāi)害預(yù)警時效性強(qiáng)的效果。其基本信息處理時序如圖1所示，專用服務(wù)器采用拉的模式，定時地從Web服務(wù)器中獲取氣象災(zāi)害預(yù)警數(shù)據(jù)，得到數(shù)據(jù)后，斷開連接，并在本地進(jìn)行處理，判斷是否為新的災(zāi)害預(yù)警，將新的災(zāi)害預(yù)警城市列表，通過推送接口傳遞給推送服務(wù)器，由推送服務(wù)器采用推的模式，將預(yù)警提醒主動推送到客戶端列表中。此時，客戶端會收到一個預(yù)警提示，客戶端向?qū)Ｓ梅?wù)器請求具體預(yù)警內(nèi)容，返回到本地手機(jī)客戶端，最終在本地客戶端以可視化的界面顯示出預(yù)警具體詳情。假設(shè)專用服務(wù)器定時地從Web服務(wù)器中拉取預(yù)警信息的時間周期為T0，災(zāi)害預(yù)警發(fā)生的時間依次為t0，t1，t2…tn，對于？坌t′，t″∈（t0，t1，t2…tn），且t″>t′，為了保證系統(tǒng)不錯過每次最新出現(xiàn)的災(zāi)害預(yù)警，則必然要滿足如下關(guān)系，即T0≤min{t| t″>t′|}。因此在氣象專用服務(wù)器上要盡可能地將拉取周期的時間間隔設(shè)置得短一些，以滿足上述關(guān)系。

1.2 推送技術(shù)方案

為實(shí)現(xiàn)實(shí)時推送，選擇推送的方案必須要考慮如下幾點(diǎn)：第一，實(shí)時性好；第二，長連接的機(jī)制能夠保證手機(jī)端流量和電量消耗較少；第三，客戶端如果掉線，最好能夠有自動重連的機(jī)制。就目前來看，為方便開發(fā)者推送服務(wù)的接入，各大移動操作系統(tǒng)平臺都集成了自己的一套推送服務(wù)接口。例如蘋果的APNS、微軟的MPNS以及谷歌的C2DM。然而就Android平臺實(shí)際使用情況來看，國內(nèi)使用谷歌的C2DM服務(wù)并不穩(wěn)定，因此，為穩(wěn)定地實(shí)現(xiàn)氣象預(yù)警災(zāi)害推送，C2DM方案并不可行。另一個在Android平臺下實(shí)現(xiàn)推送服務(wù)的方案是采用開源工程Androidpn，是基于XMPP協(xié)議實(shí)現(xiàn)的，其協(xié)議復(fù)雜冗余，沒有針對手機(jī)應(yīng)用做必要的優(yōu)化和改造，使用費(fèi)電，耗流量。經(jīng)過調(diào)查發(fā)現(xiàn)，由國內(nèi)個信互動網(wǎng)絡(luò)科技有限公司開發(fā)的推送服務(wù)可靠且相對穩(wěn)定，電量與流量消耗也相對較少，其掉線重連的機(jī)制也使得在線長連接得到了有效保障。Android應(yīng)用程序開發(fā)者提供了一系列基于Android平臺的應(yīng)用程序接口，整個體系架構(gòu)簡單，簡化了推送的開發(fā)成本，為搭建自己的推送平臺提供了一個快速的通道。因而本研究使用由該平臺提供的推送服務(wù)，其特點(diǎn)是支持文件加密透傳，開發(fā)者可以對透傳信息進(jìn)行加密，從而不必?fù)?dān)心信息的泄漏。

2 系統(tǒng)整體結(jié)構(gòu)

系統(tǒng)采用C/S的架構(gòu)可以充分利用服務(wù)端和客戶端硬件的優(yōu)勢，將繁重的計(jì)算任務(wù)交給服務(wù)端完成[9，10]，減少客戶端的計(jì)算負(fù)載，整個系統(tǒng)結(jié)構(gòu)如圖2所示。

1）專用服務(wù)器。氣象專用服務(wù)器用于分析處理氣象災(zāi)害預(yù)警信息，將需要預(yù)警的用戶列表，通過推送服務(wù)器提供的WebService，將處在災(zāi)害預(yù)警位置的客戶端列表發(fā)送給推送服務(wù)器。同時，專用服務(wù)器需要一個網(wǎng)絡(luò)IP地址和端口號，用于與客戶端的通信，包括獲取用戶位置信息、傳遞具體災(zāi)害預(yù)警信息等。

2）客戶端?；贏ndroid平臺設(shè)計(jì)的客戶端，利用Android手機(jī)提供的網(wǎng)絡(luò)定位功能和GPS定位服務(wù)定時地獲取用戶所處的地理位置，以捕捉變化的用戶位置信息，并將變化后的用戶位置提交給專用服務(wù)器，以便第一時間讓所處變化后的區(qū)域的用戶能夠接收到該地的氣象災(zāi)害預(yù)警提醒。應(yīng)用的關(guān)鍵是用戶必須在Android系統(tǒng)設(shè)置選項(xiàng)里啟用定位服務(wù)，包括GPS定位和網(wǎng)絡(luò)定位服務(wù)，否則無法實(shí)現(xiàn)與用戶位置有關(guān)的災(zāi)害預(yù)警提醒推送?？蛻舳瞬捎猛扑头?wù)提供的Android客戶端SDK，負(fù)責(zé)推送服務(wù)器的長連接通信，并利用該平臺提供的推送接口負(fù)責(zé)接收推送服務(wù)器推送過來的信息推送提醒。

3）推送服務(wù)器。直接實(shí)現(xiàn)推送信息的載體，能夠在高并發(fā)連接的情況下與客戶端保持持久的通信，向外圍提供WebService接口，接收專用服務(wù)器傳遞的推送客戶端列表，并最終將信息推送至傳遞過來的客戶端列表中。

4）Web服務(wù)器。氣象災(zāi)害預(yù)警信息的來源，由第三方氣象公共服務(wù)系統(tǒng)提供，采用格式化的XML數(shù)據(jù)，采用HTTP的通信方式為用戶提供氣象災(zāi)害預(yù)警信息。

5）數(shù)據(jù)庫。系統(tǒng)采用Oracle數(shù)據(jù)庫。數(shù)據(jù)庫與氣象專用服務(wù)器相連，在系統(tǒng)運(yùn)行時動態(tài)地更新數(shù)據(jù)庫信息。

3 系統(tǒng)設(shè)計(jì)

系統(tǒng)設(shè)計(jì)主要包括兩方面的功能，即災(zāi)害預(yù)警到來時客戶端的及時信息提醒功能和可視化的預(yù)警詳情查看功能。圖3為整個系統(tǒng)的框架模塊設(shè)計(jì)，具體包括兩個方面，即氣象專用服務(wù)器設(shè)計(jì)和Android客戶端設(shè)計(jì)。

服務(wù)器端與外圍的信息交互是雙向的，拋開整個服務(wù)器的內(nèi)部構(gòu)建來看，實(shí)際上是一個輸入-處理-輸出的系統(tǒng)處理機(jī)制。根據(jù)氣象專用服務(wù)器的功能特點(diǎn)，服務(wù)器端架構(gòu)采用分層的軟件設(shè)計(jì)思想以提高軟件未來的擴(kuò)展性能。軟件架構(gòu)包括3個層次：通信層相當(dāng)于輸入和輸出的一個接口，所有數(shù)據(jù)的傳遞和交換必須由通信層來解決，包括氣象預(yù)警資料的獲取，與推送服務(wù)器的交互以及和客戶端用戶之間的信息交互。服務(wù)層是服務(wù)器端工作的核心組件，為實(shí)時預(yù)警推送和用戶信息管理提供支持。為滿足氣象災(zāi)害預(yù)警實(shí)時性要求高的需求，該層設(shè)計(jì)了氣象災(zāi)害監(jiān)控服務(wù)，實(shí)時監(jiān)控氣象災(zāi)害預(yù)警信息的變化。系統(tǒng)服務(wù)器端采用Oracle作為數(shù)據(jù)庫系統(tǒng)的業(yè)務(wù)數(shù)據(jù)支持，提供了3種數(shù)據(jù)內(nèi)容，即歷史數(shù)據(jù)、實(shí)時預(yù)警信息數(shù)據(jù)和用戶基本信息數(shù)據(jù)。

Android客戶端采用MVC的設(shè)計(jì)理念，相對應(yīng)的3個模式為視圖顯示模式、事件控制模塊和業(yè)務(wù)數(shù)據(jù)處理。用戶在使用本系統(tǒng)軟件時，應(yīng)有一個方便簡單的入口，客戶端的視圖顯示用以解決用戶和系統(tǒng)交互的問題，是系統(tǒng)使用的功能導(dǎo)航，擁有3個用例，包括系統(tǒng)設(shè)置、預(yù)警提示和預(yù)警查看。事件控制模塊負(fù)責(zé)分發(fā)和處理相應(yīng)的業(yè)務(wù)數(shù)據(jù)請求，并將結(jié)果顯示在視圖上，是業(yè)務(wù)數(shù)據(jù)處理和視圖顯示的一座橋梁，在Android系統(tǒng)中主要由Activity完成。業(yè)務(wù)數(shù)據(jù)處理模塊是MVC 3層架構(gòu)中的數(shù)據(jù)模型，是客戶端數(shù)據(jù)處理的核心組件。

4 關(guān)鍵技術(shù)的實(shí)現(xiàn)與分析

4.1 基于位置的信息采集

Android客戶端提供了兩種不同的定位方式：網(wǎng)絡(luò)定位和GPS定位。用戶的位置通常是動態(tài)變化的，但變化范圍絕大部分又限于一定區(qū)域之內(nèi)，如果在一個小的區(qū)域范圍之內(nèi)變化，可以視為沒有發(fā)生位置改變，對于氣象預(yù)警的結(jié)果沒有什么影響。本系統(tǒng)中以一個行政規(guī)劃區(qū)（以市級單位為例）為地理變化單位。為方便將地理的經(jīng)緯度轉(zhuǎn)換為相應(yīng)的地理位置信息，Android手機(jī)端采用百度定位SDK。為使服務(wù)器知道用戶最新地理位置信息，筆者采取了如下的解決方案：首先由用戶通過系統(tǒng)設(shè)置選項(xiàng)，設(shè)置好定位時間間隔，并保存到系統(tǒng)參數(shù)的配置文件中；其次開啟Android后臺服務(wù)（Service），在主線程中注冊百度定位監(jiān)聽，并讀取系統(tǒng)參數(shù)配置文件，設(shè)置好定位時間間隔；最后通過百度地理定位監(jiān)聽方法onReceiveLocation（BDLocation location），獲取用戶當(dāng)前地理位置信息LocUpdate，同時把本次地理位置信息更新到本地數(shù)據(jù)庫中，從數(shù)據(jù)庫中讀取用戶上一個地理位置區(qū)域LocPrevious，并做兩次位置對比，如果位置不同，則啟用位置更新方法LocNotify Server（String LocUpdate），將用戶最新位置信息通知給服務(wù)器。

4.2 預(yù)警信息推送

在系統(tǒng)運(yùn)行中，氣象專用服務(wù)器要定時地從Web服務(wù)器端拉取氣象災(zāi)害預(yù)警信息數(shù)據(jù)并做處理，將最新的預(yù)警數(shù)據(jù)存到實(shí)時預(yù)警信息數(shù)據(jù)表中，同時將歷史氣象預(yù)警信息插入到歷史數(shù)據(jù)表中，因而實(shí)時預(yù)警信息表中的內(nèi)容是動態(tài)變化的。鑒于氣象災(zāi)害預(yù)警的及時性要求，本系統(tǒng)的預(yù)警信息推送采用了兩種機(jī)制保證信息的及時性：實(shí)時預(yù)警信息監(jiān)控機(jī)制和實(shí)時推送服務(wù)。每次服務(wù)器端氣象數(shù)據(jù)獲取模塊拉取的氣象預(yù)警數(shù)據(jù)要與上一次的預(yù)警數(shù)據(jù)進(jìn)行對比，并將最新的預(yù)警數(shù)據(jù)存到實(shí)時預(yù)警表中，同時將過期的氣象預(yù)警信息刪掉，以保證實(shí)時預(yù)警表中的數(shù)據(jù)都是最新的預(yù)警數(shù)據(jù)。這樣實(shí)時預(yù)警信息表中的數(shù)據(jù)都有一定的生命周期，而其生命周期就是定時拉取Web服務(wù)端的時間間隔，設(shè)為T0。監(jiān)控模塊要開啟定時器定時地掃描實(shí)時預(yù)警信息表中的數(shù)據(jù)，檢查是否存在最新預(yù)警信息。由于不能重復(fù)向用戶發(fā)送預(yù)警信息，也不能讓用戶錯過預(yù)警信息，定時器的選擇要與實(shí)時預(yù)警數(shù)據(jù)的生命周期（T0）一致。其處理流程如圖4所示。

4.3 可視化氣象災(zāi)害預(yù)警顯示

手機(jī)端結(jié)合百度地圖以可視化的方式為用戶提供災(zāi)害預(yù)警的查看方式。本地出現(xiàn)氣象災(zāi)害時，會在手機(jī)端通知欄出現(xiàn)災(zāi)害預(yù)警提醒標(biāo)志，當(dāng)用戶點(diǎn)擊預(yù)警標(biāo)題時，就會跳轉(zhuǎn)到氣象災(zāi)害預(yù)警頁面，如圖5所示。

1）Android異步線程實(shí)現(xiàn)。當(dāng)用戶啟動一個頁面時，系統(tǒng)會分配一個默認(rèn)的主線程給相應(yīng)的頁面，但是要獲取實(shí)時預(yù)警信息，實(shí)現(xiàn)與氣象專用服務(wù)器端信息的交互，應(yīng)避免直接在主線程中實(shí)現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)下載，否則可能導(dǎo)致主線程堵塞，影響用戶的使用體驗(yàn)。因此，該模塊中采用了基于Android平臺異步線程的設(shè)計(jì)方案，當(dāng)啟動主線程后，開啟一個實(shí)時預(yù)警信息下載線程，下載完數(shù)據(jù)后，利用Android提供的線程間傳遞信息機(jī)制，在該線程中向主線程發(fā)送通知，由主線程將下載完的數(shù)據(jù)顯示到頁面上。

2）用戶圖層位置顯示。為了給用戶一個良好的用戶交互界面，方便用戶預(yù)警的定位以及查看周邊的情況，系統(tǒng)采用了百度地圖實(shí)現(xiàn)和用戶的交互。系統(tǒng)主要利用百度地圖提供的MapView、MapController接口實(shí)現(xiàn)地圖的顯示和地圖的操作。通過實(shí)現(xiàn)BDLocationListener接口中onReceiveLocation（BDLocation location）方法以獲得用戶精準(zhǔn)的地理位置定位，同時自定義自己的圖層類，通過繼承百度地圖ItemizedOverlay類，重寫其中的draw方法，以圓形陰影區(qū)域顯示用戶周邊情況，最終通過MapView將自定義的圖層疊加到底圖上，從而實(shí)現(xiàn)更加豐富的圖層顯示。

4.4 流量分析

氣象預(yù)警信息資料處理的時效性和基于手機(jī)端的流量控制是本系統(tǒng)應(yīng)用的特色。以1 d的全國各地氣象預(yù)警信息發(fā)布為例，從內(nèi)容和數(shù)目上看，多則數(shù)十條的氣象預(yù)警發(fā)布條目，少則僅有幾條甚至沒有氣象預(yù)警的發(fā)布；從發(fā)布頻率上看，也是難以估計(jì)的，這與氣候、季節(jié)和地域密切相關(guān)，其結(jié)果存在著隨機(jī)性。在同等條件下，服務(wù)器端輪詢拉取氣象預(yù)警信息和客戶端輪詢拉取Web氣象預(yù)警信息頻率一樣的情況下，采用推拉混合機(jī)制模式對客戶端流量控制要明顯優(yōu)于單一的手機(jī)端輪詢機(jī)制，圖6為在輪詢周期間隔為0.5 h，流量監(jiān)控采樣周期為1.0 h的情況下兩者流量對比分析。從圖6中可以看出，混合機(jī)制對手機(jī)的流量控制要優(yōu)于手機(jī)端輪詢機(jī)制，而且在同時提高輪詢頻率、增加預(yù)警時效性的情況下，混合機(jī)制的流量控制優(yōu)勢更加明顯。試驗(yàn)結(jié)果受網(wǎng)絡(luò)環(huán)境和Web氣象預(yù)警發(fā)布的頻率制約，通常情況下網(wǎng)絡(luò)環(huán)境不好時流量消耗會略微提高。

5 結(jié)語

本系統(tǒng)以Android手機(jī)終端作為預(yù)警信息傳播媒介，初步實(shí)現(xiàn)了基于用戶地理位置的預(yù)警信息推送，用戶不再需要自己去手動獲取預(yù)警信息，而是由服務(wù)器端實(shí)時地根據(jù)用戶所處的地理位置實(shí)現(xiàn)智能化的預(yù)警信息推送。系統(tǒng)的研究工作雖然是在氣象預(yù)警背景下提出與實(shí)施的，但是對于其他行業(yè)，例如城市交通管理、農(nóng)業(yè)氣象災(zāi)害預(yù)報等都具有一定的參考價值與意義。

參考文獻(xiàn)：

[1] 易烈剛，陳官清，張強(qiáng)宜.基于B/S模式的氣象預(yù)警信息發(fā)布平臺設(shè)計(jì)[J].貴州氣象，2009，33（5）：32-33.

[2] 王 赟，段燕楠，姚 愚，等.氣象預(yù)警信息綜合發(fā)布平臺的設(shè)計(jì)與實(shí)現(xiàn)[J].成都信息工程學(xué)院學(xué)報，2011，26（6）：656-662.

[3] 孫曉宇.Android手機(jī)界面管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2009.

[4] 公 磊，周 聰.基于Android的移動終端應(yīng)用程序開發(fā)與研究[J].計(jì)算機(jī)與現(xiàn)代化，2008（8）：85-89.

[5] 何文華.基于地理位置及時信息推送服務(wù)分析及Shopylife的設(shè)計(jì)與實(shí)現(xiàn)[D].成都：電子科技大學(xué)，2012.

[6] 王 翔，李慶華，張峰軍.基于LBS的智能推送技術(shù)研究[J].通信技術(shù)，2011，44（12）：95-97.

[7] 曹海兵，夏 英.Push型LBS應(yīng)用的實(shí)現(xiàn)技術(shù)研究[J].計(jì)算機(jī)應(yīng)用研究，2006（10）：232-233.

[8] 李志飛，萬麟瑞，胡 宏，等.WAP應(yīng)用中的PUSH/PULL集成機(jī)制研究[J].小型微型計(jì)算機(jī)系統(tǒng)，2001，22（10）：1178-1181.

[9] 田 韜，張悠慧，汪東升.基于C/S架構(gòu)的可擴(kuò)展嵌入式系統(tǒng)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2008，29（7）：1804-1807.

[10] 馬 翔.基于.NET的工作流程審批系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2012，33（11）：4187-4190.