基于LBS的氣象預警Android平臺設計

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

關鍵詞：氣象預警；基于位置的服務（LBS）；Android平臺

中圖分類號：S421；TP302.1 文獻標識碼：A 文章編號：0439-8114（2013）24-6161-05

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

由于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完成。業務數據處理模塊是MVC 3層架構中的數據模型，是客戶端數據處理的核心組件。

4 關鍵技術的實現與分析

4.1 基于位置的信息采集

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

4.2 預警信息推送

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

4.3 可視化氣象災害預警顯示

手機端結合百度地圖以可視化的方式為用戶提供災害預警的查看方式。本地出現氣象災害時，會在手機端通知欄出現災害預警提醒標志，當用戶點擊預警標題時，就會跳轉到氣象災害預警頁面，如圖5所示。

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

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

4.4 流量分析

氣象預警信息資料處理的時效性和基于手機端的流量控制是本系統應用的特色。以1 d的全國各地氣象預警信息發布為例，從內容和數目上看，多則數十條的氣象預警發布條目，少則僅有幾條甚至沒有氣象預警的發布；從發布頻率上看，也是難以估計的，這與氣候、季節和地域密切相關，其結果存在著隨機性。在同等條件下，服務器端輪詢拉取氣象預警信息和客戶端輪詢拉取Web氣象預警信息頻率一樣的情況下，采用推拉混合機制模式對客戶端流量控制要明顯優于單一的手機端輪詢機制，圖6為在輪詢周期間隔為0.5 h，流量監控采樣周期為1.0 h的情況下兩者流量對比分析。從圖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.

[9] 田 韜，張悠慧，汪東升.基于C/S架構的可擴展嵌入式系統[J].計算機工程與設計，2008，29（7）：1804-1807.

[10] 馬 翔.基于.NET的工作流程審批系統設計與實現[J].計算機工程與設計，2012，33（11）：4187-4190.