地震預(yù)警信息快速發(fā)布系統(tǒng)研究1

蔡 寅 張 明 趙 瑞 尹玉振 李 紅

1）中國地震局地球物理研究所，北京 100081

2）山東省地震局，濟(jì)南 250014

引言

現(xiàn)今，地震預(yù)報(bào)仍沒有實(shí)現(xiàn)重大突破，地震預(yù)警系統(tǒng)（Earthquake Early Warning System，EEWS）是世界上公認(rèn)的能夠有效減輕地震災(zāi)害的新技術(shù)手段之一（Xu等，2017；Festa等，2018）。地震預(yù)警信息發(fā)布系統(tǒng)需要在破壞性地震波到達(dá)前，以最小的延遲，通過最便捷的方式，告知用戶最精準(zhǔn)的地震信息，達(dá)到緊急避險(xiǎn)和決策應(yīng)對(duì)的目的（Gasparini等，2014；Cauzzi等，2016）。作為服務(wù)于民生的“最后一公里”，預(yù)警信息的快速發(fā)布是整個(gè)地震預(yù)警系統(tǒng)在社會(huì)服務(wù)中的重要體現(xiàn)（蔡寅等，2016）。

自2004年開始，在全國范圍內(nèi)運(yùn)行的地震速報(bào)信息共享服務(wù)系統(tǒng)（Earthquake Instant Messenger，EQIM）實(shí)現(xiàn)了省級(jí)臺(tái)網(wǎng)與國家臺(tái)網(wǎng)之間地震速報(bào)信息的交換與共享，并以短信的方式快速發(fā)布（楊陳等，2009）。地震預(yù)警系統(tǒng)僅能提供數(shù)秒或數(shù)十秒的預(yù)警時(shí)間，若以短信方式發(fā)送預(yù)警信息，一方面短信的固有延遲性已經(jīng)不能滿足公眾對(duì)信息時(shí)效性的需求，另一方面所有短信用戶接收到的信息是完全一致的。然而，由于用戶所在區(qū)域場(chǎng)地的差異以及距離震中遠(yuǎn)近的不同，致使所受到地震的破壞程度也有所差異，地震預(yù)警系統(tǒng)對(duì)于不同位置的用戶所推送的預(yù)警信息也不盡相同。因此，需要考慮其它方式實(shí)現(xiàn)地震預(yù)警信息的快速發(fā)布。

近年來，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，尤其是移動(dòng)互聯(lián)網(wǎng)的普及，基于地理位置的信息服務(wù)（Location Based Services，LBS）逐漸成為1種新興的增值業(yè)務(wù)形式，為用戶提供與所在位置有關(guān)的服務(wù)（劉成，2013；Vanjire等，2014）。面向公眾的地震預(yù)警恰恰與用戶所在的位置信息有極大的關(guān)系，如果有效地結(jié)合LBS與GIS（Geographic Information System，地理信息系統(tǒng)）2種技術(shù)，融合地理信息數(shù)據(jù)與用戶位置信息，將能夠?yàn)橛脩籼峁┚W(wǎng)絡(luò)化與個(gè)性化的地震預(yù)警信息服務(wù)（趙慶展等，2015）。

本文針對(duì)移動(dòng)互聯(lián)網(wǎng)用戶與桌面用戶，通過分析對(duì)比，選擇MQTT協(xié)議與JSON技術(shù)作為服務(wù)端與客戶端的數(shù)據(jù)交互方式，提出1種支持海量并發(fā)式的地震預(yù)警信息推送架構(gòu)，設(shè)計(jì)并實(shí)現(xiàn)了一體化地震預(yù)警信息發(fā)布系統(tǒng)。經(jīng)綜合測(cè)試，系統(tǒng)能夠?yàn)楦黝惢ヂ?lián)網(wǎng)用戶提供基于位置的地震預(yù)警信息服務(wù)，在破壞性地震波到達(dá)前，為公眾緊急避險(xiǎn)爭(zhēng)取了最大限度的自救時(shí)間。

1 系統(tǒng)總體架構(gòu)

地震預(yù)警信息發(fā)布系統(tǒng)由服務(wù)端與客戶端2部分組成。服務(wù)端完成地震預(yù)警信息的實(shí)時(shí)推送，客戶端獲取預(yù)警信息后進(jìn)行前端展現(xiàn)報(bào)警。客戶端主要面向移動(dòng)互聯(lián)網(wǎng)用戶與桌面用戶設(shè)計(jì)開發(fā)，因而又細(xì)分為移動(dòng)端與桌面端，分別選用Android與WebGIS平臺(tái)作為開發(fā)環(huán)境。從整體架構(gòu)角度分析，系統(tǒng)為C/S（Client/Server，客戶端/服務(wù)器架構(gòu)）與B/S（Browser/Server，瀏覽器/服務(wù)器架構(gòu)）的混合架構(gòu)。系統(tǒng)借鑒了經(jīng)典的三層架構(gòu)設(shè)計(jì)模式，增加了服務(wù)層，實(shí)現(xiàn)邏輯層多類用戶預(yù)警參數(shù)計(jì)算與數(shù)據(jù)層多種數(shù)據(jù)源間的服務(wù)封裝與數(shù)據(jù)交互，目的是將數(shù)據(jù)資源與分析展現(xiàn)的完全解耦，為今后接入不同的終端設(shè)備或平臺(tái)用戶提供可擴(kuò)展的服務(wù)接口（Mantas等，2015）。系統(tǒng)邏輯架構(gòu)如圖1所示。

圖1 地震預(yù)警信息發(fā)布系統(tǒng)邏輯架構(gòu) Fig.1 The logical architecture of earthquake early warning information rapid release system

數(shù)據(jù)層由內(nèi)部數(shù)據(jù)庫與外部數(shù)據(jù)源組成。其中，內(nèi)部數(shù)據(jù)庫以用戶信息數(shù)據(jù)庫為主體，通過多種定位方式（GPS、Wi-Fi、移動(dòng)通信網(wǎng)絡(luò)）獲取用戶位置信息，將其與用戶的基礎(chǔ)數(shù)據(jù)、所在位置的場(chǎng)地響應(yīng)數(shù)據(jù)及地理信息數(shù)據(jù)（離線數(shù)據(jù)）進(jìn)行關(guān)聯(lián)，提供給上層進(jìn)行預(yù)警參數(shù)計(jì)算及信息展示；外部數(shù)據(jù)源主要由提供發(fā)震時(shí)刻、震中位置、極震區(qū)烈度等信息的震源參數(shù)數(shù)據(jù)庫和提供實(shí)時(shí)地理信息的在線式地圖數(shù)據(jù)組成。

服務(wù)層負(fù)責(zé)完成數(shù)據(jù)層與邏輯層之間的數(shù)據(jù)交互，通過封裝標(biāo)準(zhǔn)Web Service接口服務(wù)，自動(dòng)適配各類數(shù)據(jù)源，實(shí)時(shí)獲取數(shù)據(jù)層資源，將震源參數(shù)及用戶信息以多線程的方式發(fā)送給邏輯層。對(duì)用戶的反饋數(shù)據(jù)或更新的定制信息，服務(wù)層將其保存至數(shù)據(jù)層的用戶信息數(shù)據(jù)庫，作為系統(tǒng)日志進(jìn)行管理。針對(duì)混合型邏輯架構(gòu)，融合2種交互技術(shù)，實(shí)現(xiàn)多類終端海量用戶的高并發(fā)信息服務(wù)。

邏輯層以預(yù)警信息消息傳遞模塊為核心，面向各類終端用戶的服務(wù)請(qǐng)求，支持海量用戶的并發(fā)接入操作，通過服務(wù)層將每一報(bào)的震源參數(shù)向下保存至數(shù)據(jù)層的用戶信息數(shù)據(jù)庫。同時(shí)，將震源參數(shù)以服務(wù)的方式提供給基于位置的預(yù)警參數(shù)計(jì)算模塊。計(jì)算模塊結(jié)合用戶所在的地理位置和場(chǎng)地響應(yīng)因子，快速估算每個(gè)在線用戶的地震預(yù)警信息，向展現(xiàn)層提供需要推送的預(yù)警信息。此外，邏輯層負(fù)責(zé)與服務(wù)層建立持久化連接，確保預(yù)警信息推送的高可用性。

展現(xiàn)層分別面向Android和Web平臺(tái)用戶，實(shí)現(xiàn)基于GIS和LBS的地震預(yù)警信息的可視化展現(xiàn)，在客戶端以地震波動(dòng)態(tài)擴(kuò)散、聲音振動(dòng)報(bào)警以及倒計(jì)時(shí)提醒等多種方式提示用戶緊急避險(xiǎn)。雖然兩大平臺(tái)實(shí)現(xiàn)預(yù)警信息發(fā)布的技術(shù)不盡相同，但兩者在信息展現(xiàn)的方式和用戶體驗(yàn)的效果上仍保持一致。

2 數(shù)據(jù)交互方式

一般情況下，地震預(yù)警系統(tǒng)僅能為公眾提供幾十秒甚至幾秒的避險(xiǎn)時(shí)間，每提前1s接收到地震預(yù)警信息，都將有效減少更多的人員傷亡與經(jīng)濟(jì)損失。這就意味著預(yù)警信息發(fā)布對(duì)系統(tǒng)響應(yīng)時(shí)間有較高的需求，需要考慮信息從服務(wù)端至客戶端傳輸?shù)母鱾€(gè)環(huán)節(jié)中降低時(shí)間延時(shí)，因此，選擇1種高效的數(shù)據(jù)交互機(jī)制至關(guān)重要。

2.1 與Android端數(shù)據(jù)交互

目前，基于Android移動(dòng)平臺(tái)的主流信息推送方案有3種：C2DM（Cloud to Device Messaging，云端推送）、MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸協(xié)議）及XMPP（Extensible Messaging and Presence Protocol，可擴(kuò)展通訊和表示協(xié)議）。其中，C2MD是谷歌公司為應(yīng)用開發(fā)者提供的1項(xiàng)服務(wù)，實(shí)現(xiàn)從服務(wù)器向Android應(yīng)用程序發(fā)送數(shù)據(jù)，但信息發(fā)送過程需要綁定谷歌賬號(hào)，在國內(nèi)使用具有一定局限性；XMPP協(xié)議技術(shù)成熟，標(biāo)準(zhǔn)化程度高，功能強(qiáng)大，具有較強(qiáng)的可擴(kuò)展性，但其缺點(diǎn)是數(shù)據(jù)負(fù)載過重，導(dǎo)致終端流量及電量消耗過高（關(guān)慶余等，2014）；MQTT協(xié)議1種輕量級(jí)的基于代理的發(fā)布、訂閱消息傳輸協(xié)議，目前已成為物聯(lián)網(wǎng)傳輸標(biāo)準(zhǔn)協(xié)議之一，由于其低功耗、數(shù)據(jù)包較?。ü潭▓?bào)頭僅為2字節(jié)）、分布式等特點(diǎn)，MQTT成為實(shí)現(xiàn)移動(dòng)應(yīng)用的理想選擇，因此，也是地震預(yù)警信息推送的首選解決方案（許金喜等，2015）。

實(shí)現(xiàn)MQTT消息代理的開源項(xiàng)目較多，但在實(shí)際應(yīng)用中表現(xiàn)各異。本文從CUP占用率及數(shù)據(jù)傳輸延時(shí)的角度，對(duì)比測(cè)試了目前主流代理服務(wù)器在支持不同用戶數(shù)量方面的表現(xiàn)。參與測(cè)試的代理服務(wù)器包括Apollo 1.7、ActiveMQ 5.10.0、Mosquitto 1.3.5及RabbitMQ 3.4.2。在相同的硬件環(huán)境下（CPU：E8400 3.00GHz，內(nèi)存：4GB），各代理服務(wù)器CPU占用率及數(shù)據(jù)傳輸延時(shí)的結(jié)果如圖2、3所示，ActiveMQ因無法支持2000個(gè)以上的用戶同時(shí)并發(fā)信息，其測(cè)試結(jié)果在圖中并未標(biāo)出。

圖2 MQTT服務(wù)器CPU占用率測(cè)試結(jié)果 Fig.2 Test result for the CPU occupancy of MQTT servers

圖3 MQTT服務(wù)器響應(yīng)延時(shí)測(cè)試結(jié)果 Fig.3 Test result for response latency of MQTT servers

測(cè)試結(jié)果表明，Mosquitto在資源占用率、數(shù)據(jù)傳輸延時(shí)及并發(fā)用戶支持?jǐn)?shù)量等方面的表現(xiàn)均為最優(yōu)。RabbitMQ并發(fā)能力極大地依賴于CPU性能，當(dāng)每秒并發(fā)數(shù)超過8000時(shí)，CUP占用率超過70%，出現(xiàn)內(nèi)存溢出現(xiàn)象；當(dāng)Apollo每秒并發(fā)操作超過1萬個(gè)時(shí)，系統(tǒng)延時(shí)快速增長(zhǎng)，超過2萬后，系統(tǒng)延時(shí)超過1s，不能滿足業(yè)務(wù)需求；盡管CPU占用率較高，但Mosquitto仍然能夠支持6萬個(gè)用戶的并發(fā)操作，數(shù)據(jù)延時(shí)也小于1s，但超過6萬用戶時(shí)，會(huì)出現(xiàn)內(nèi)存溢出，其可能的原因是Mosquitto自身單線程的處理方式，6萬用戶為處理上限，這也解釋了雙核CPU使用率始終處于50%水平的現(xiàn)象。

2.2 與Web端數(shù)據(jù)交互

盡管XML（Extensible Markup Language，擴(kuò)展標(biāo)記語言）早已成為業(yè)界公認(rèn)的Web數(shù)據(jù)交換的標(biāo)準(zhǔn)格式，但服務(wù)端和客戶端都需要占用大量資源，消耗大量時(shí)間來解析XML文件，導(dǎo)致整體效率較低。與XML不同，JSON（JavaScript Object Notation，JavaScript對(duì)象表示法）作為1種輕量級(jí)的數(shù)據(jù)交換格式，更加簡(jiǎn)單和靈活，對(duì)元素的定義也更加精練，占用更小的空間資源，易于機(jī)器的解析和生成。并且，JSON是與編程語言無關(guān)的普通文本文件，不需要編譯和執(zhí)行，這些特性使JSON成為地震預(yù)警信息發(fā)布Web端的首選數(shù)據(jù)交換格式（韓敏等，2010）。以1條預(yù)定義的預(yù)警信息的為例，JSON所用的字節(jié)數(shù)明顯小于XML格式，代碼對(duì)比見表1。

表1 XML與JSON格式預(yù)警信息代碼對(duì)比 Table1 Code format of early warning information between XML and JSON

相對(duì)XML，1條JSON格式的預(yù)警信息即減少了75字節(jié)的數(shù)據(jù)量，當(dāng)用戶量和數(shù)據(jù)量增大后，其優(yōu)勢(shì)更加突出。在元素規(guī)模較大的情況下，JSON傳輸所消耗的時(shí)間遠(yuǎn)遠(yuǎn)小于XML；隨著測(cè)試預(yù)警信息元素?cái)?shù)量的逐漸增加，JSON的傳輸速率沒有明顯變化，而XML出現(xiàn)線性增長(zhǎng)的趨勢(shì)，如圖4所示。此外，客戶端需要對(duì)服務(wù)器端傳來的數(shù)據(jù)進(jìn)行反序列化才能獲取有效的數(shù)據(jù)。XML自身基于文檔對(duì)象模型（Document Object Mode，DOM）樹結(jié)構(gòu)，進(jìn)行反序列化時(shí)需要考慮父節(jié)點(diǎn)和子節(jié)點(diǎn)的相應(yīng)解析，這為反序列化過程增加了難度（于京等，2012）；而基于JavaScript腳本語言的JSON，自身語法非常簡(jiǎn)潔，屏蔽了DOM解析的復(fù)雜度，大大降低了反序列化時(shí)的冗余度，反序列化時(shí)間也明顯小于XML，如圖5所示。因此，采用JSON作為數(shù)據(jù)交換格式，可以最大限度地降低通訊延遲，有利于提高系統(tǒng)的響應(yīng)速度，保證預(yù)警信息的時(shí)效性。

圖4 不同元素?cái)?shù)量的傳輸延時(shí)測(cè)試結(jié)果 Fig.4 Test result for response latency between XML and JSON

圖5 反序列化耗時(shí)測(cè)試結(jié)果 Fig.5 Test result for time consuming of anti-serialization between XML and JSON

3 核心邏輯設(shè)計(jì)

3.1 服務(wù)端設(shè)計(jì)

地震預(yù)警信息服務(wù)端軟件從震源參數(shù)數(shù)據(jù)庫獲取參數(shù)信息（發(fā)震時(shí)刻、震中位置、震級(jí)、震中區(qū)烈度），根據(jù)不同接收終端的信息傳輸協(xié)議，將參數(shù)信息推送至各類客戶端接收軟件。當(dāng)服務(wù)端獲取來自不同數(shù)據(jù)源的地震預(yù)警信息后，首先進(jìn)行數(shù)據(jù)解析，對(duì)需要發(fā)布的信息進(jìn)行編碼轉(zhuǎn)換，形成標(biāo)準(zhǔn)化的預(yù)警信息；其次，根據(jù)不同客戶端的數(shù)據(jù)交互方式，按照MQTT協(xié)議及JSON數(shù)據(jù)格式封裝為地震預(yù)警信息包，分別并發(fā)推送至移動(dòng)端與Web端。推送完成后，監(jiān)聽客戶端的反饋信息，判斷信息是否推送成功，如推送成功，則創(chuàng)建預(yù)警信息服務(wù)日志，否則重新推送，直至獲得正確的反饋信息。地震預(yù)警信息發(fā)布服務(wù)端的邏輯流程如圖6所示。

3.2 客戶端設(shè)計(jì)

地震預(yù)警信息客戶端軟件在接收到預(yù)警信息后，對(duì)數(shù)據(jù)進(jìn)行解析計(jì)算，形成向用戶展現(xiàn)的圖形要素，在前端進(jìn)行可視化展現(xiàn)。當(dāng)客戶端啟動(dòng)應(yīng)用服務(wù)后，首先向服務(wù)端發(fā)送服務(wù)請(qǐng)求，訂閱預(yù)警信息包，通過定時(shí)發(fā)送心跳包與服務(wù)端保持長(zhǎng)連接；同時(shí)，獲取客戶端位置信息，根據(jù)定位精度的不同，定位方式優(yōu)先級(jí)依次為GPS定位、Wi-Fi定位和移動(dòng)網(wǎng)絡(luò)定位。當(dāng)客戶端接收到服務(wù)端推送的地震預(yù)警信息后，將結(jié)合客戶端此時(shí)的位置信息，分別按公式（1）—（3）計(jì)算震中距D、用戶所在位置烈度I和對(duì)P波、S波的預(yù)警時(shí)間TP、TS，以逐秒動(dòng)態(tài)的方式在前端進(jìn)行展現(xiàn)，并通過聲音或震動(dòng)方式進(jìn)行報(bào)警，同時(shí)向服務(wù)端發(fā)送響應(yīng)包，完成1次預(yù)警信息發(fā)布的完整過程。地震預(yù)警信息發(fā)布客戶端的邏輯流程如圖7所示。

圖6 地震預(yù)警信息發(fā)布服務(wù)端邏輯流程 Fig.6 The logical flow chart of server-side

其中，D為震中距（km）；（α1，β1）為用戶所在位置的經(jīng)緯度坐標(biāo)；（α2，β2）為震中位置的經(jīng)緯度坐標(biāo)；R為地球半徑，設(shè)定為6371km。

其中，I0為震中烈度。

其中，VP、VS分別為P波、S波的傳播速度（km/s）；Tnow為當(dāng)前時(shí)間；Teq為發(fā)震時(shí)間。

圖7 地震預(yù)警信息發(fā)布客戶端邏輯流程 Fig.7 The logical flow chart of client-side

4 系統(tǒng)實(shí)現(xiàn)與測(cè)試

根據(jù)上述系統(tǒng)總體架構(gòu)及核心邏輯設(shè)計(jì)，開發(fā)實(shí)現(xiàn)了地震預(yù)警信息發(fā)布系統(tǒng)。根據(jù)各子系統(tǒng)部署所在物理位置及用戶類別的角度，從服務(wù)端、客戶端及綜合管理3方面進(jìn)行功能劃分。服務(wù)端子系統(tǒng)與綜合管理子系統(tǒng)分別包含5個(gè)子模塊，客戶端子系統(tǒng)功能模塊較多，共包含25個(gè)功能模塊。系統(tǒng)功能模塊樹狀圖見圖8。

圖8 地震預(yù)警信息發(fā)布系統(tǒng)功能模塊樹 Fig.8 The function tree component of the earthquake early warning information rapid release system

為檢驗(yàn)軟件系統(tǒng)是否符合預(yù)期目標(biāo)，在對(duì)系統(tǒng)的功能模塊及兼容性測(cè)試后，重點(diǎn)對(duì)軟件的實(shí)時(shí)性及可靠性進(jìn)行測(cè)試，確定系統(tǒng)運(yùn)行時(shí)服務(wù)端與客戶端的性能表現(xiàn)。測(cè)試方式是在虛擬機(jī)的環(huán)境下，部署服務(wù)端軟件，模擬每30s向客戶端推送預(yù)警信息，并發(fā)用戶量為2萬以內(nèi)的隨機(jī)數(shù)，連續(xù)推送24小時(shí)，通過響應(yīng)時(shí)間（從服務(wù)端發(fā)送預(yù)警信息到客戶端收到預(yù)警信息并展現(xiàn)所需的時(shí)間）與信息接收率2方面測(cè)試系統(tǒng)的整體性能。針對(duì)Android客戶端軟件，增加了耗電量的測(cè)試。

4.1 Web端

Web端地震預(yù)警信息發(fā)布軟件整體采用RIA（Rich Internet Application，富客戶端應(yīng)用）模式，通過Java語言完成JSON數(shù)據(jù)包的反序列化處理，對(duì)解析后的數(shù)據(jù)，采用HTML5語言實(shí)現(xiàn)WebGIS功能與地震預(yù)警信息的疊加展現(xiàn)。富客戶端應(yīng)用模式不僅降低了系統(tǒng)部署的復(fù)雜度和服務(wù)端的計(jì)算壓力，提高了系統(tǒng)整體響應(yīng)速度，同時(shí)也實(shí)現(xiàn)了無刷新的動(dòng)態(tài)展現(xiàn)的預(yù)警信息，給用戶帶來更好的操作體驗(yàn)。

Web端預(yù)警信息發(fā)布軟件能夠?qū)φ鹪葱畔⑦M(jìn)行滾動(dòng)發(fā)布，標(biāo)注用戶位置（Wi-Fi網(wǎng)絡(luò)定位）與震中位置，計(jì)算地震預(yù)警信息，通過動(dòng)態(tài)的形式展現(xiàn)P、S波擴(kuò)散過程，并以倒計(jì)時(shí)方式配合聲音報(bào)警提示用戶預(yù)警時(shí)間，如圖9所示。通過24小時(shí)連續(xù)測(cè)試，客戶端在Wi-Fi網(wǎng)絡(luò)環(huán)境下的平均響應(yīng)時(shí)間為460ms。由于網(wǎng)絡(luò)狀態(tài)相對(duì)穩(wěn)定，測(cè)試結(jié)果未出現(xiàn)丟包或二次推送的情況，客戶端能夠100%接收到預(yù)警信息。

圖9 WebGIS端預(yù)警信息發(fā)布效果 Fig.9 Actual effect map of the early warning information release in WebGIS

4.2 Android端

Android端地震預(yù)警信息發(fā)布軟件基于Android操作系統(tǒng)原生開發(fā)，采用ViewStub動(dòng)態(tài)布局顯示技術(shù)完成用戶界面設(shè)計(jì)，有效減少了對(duì)資源的占用，降低了信息接收的延遲。通過調(diào)用高德開放平臺(tái)的地圖數(shù)據(jù)，構(gòu)建地理信息數(shù)據(jù)資源，完成預(yù)警信息、位置信息及地理信息的疊加渲染。用戶可根據(jù)需求定制預(yù)警服務(wù)內(nèi)容，設(shè)置交互模式及信息接收方式，滿足各種場(chǎng)景下對(duì)地震預(yù)警信息的需求。

在接收到預(yù)警信息后，移動(dòng)端預(yù)警信息發(fā)布軟件首先以振動(dòng)及聲音報(bào)警的形式提醒用戶查看信息，同時(shí)自動(dòng)彈出地震預(yù)警基本信息頁面，如圖10（a）所示。用戶可以點(diǎn)擊查看地震波擴(kuò)散的動(dòng)態(tài)過程，如圖10（b）所示。為統(tǒng)一客戶端軟件的風(fēng)格，在顯示內(nèi)容與展現(xiàn)形式上與Web端基本一致。

為充分反映不同網(wǎng)絡(luò)環(huán)境下的系統(tǒng)響應(yīng)時(shí)間，分別選擇Wi-Fi和4G無線網(wǎng)絡(luò)環(huán)境進(jìn)行24小時(shí)連續(xù)測(cè)試。在Wi-Fi網(wǎng)絡(luò)環(huán)境下，系統(tǒng)的平均響應(yīng)時(shí)間為318ms，客戶端能100%接收到預(yù)警信息；在4G網(wǎng)絡(luò)環(huán)境下，由于網(wǎng)絡(luò)波動(dòng)較大，系統(tǒng)的平均響應(yīng)時(shí)間為705ms，查詢系統(tǒng)日志記錄發(fā)現(xiàn)有1.7%的預(yù)警信息通過二次推送完成，一定程度上增加了系統(tǒng)的響應(yīng)時(shí)間。

圖10 移動(dòng)端預(yù)警信息發(fā)布效果 Fig.10 Actual effect map of the early warning information release in Android

最后，采用AccuBattery軟件，測(cè)試Android端軟件的耗電量。在空載狀態(tài)下，即Android客戶端程序在后臺(tái)運(yùn)行，定時(shí)發(fā)送心跳包保持與服務(wù)端的長(zhǎng)連接，選取發(fā)送時(shí)間間隔為5分鐘，經(jīng)24小時(shí)連續(xù)測(cè)試，消耗電量為24.08mAh。按照一般手機(jī)電池容量為3000mAh計(jì)算，Android端軟件每天的電量消耗占比小于1%，幾乎可以忽略不計(jì)。

5 結(jié)論

本文基于互聯(lián)網(wǎng)技術(shù)，面向移動(dòng)端及桌面端用戶，提出了地震預(yù)警信息發(fā)布系統(tǒng)總體架構(gòu)設(shè)計(jì)方案。通過對(duì)比分析，選定MQTT協(xié)議及JSON格式作為服務(wù)端與客戶端數(shù)據(jù)交互方式。根據(jù)業(yè)務(wù)需求，結(jié)合GIS及LBS技術(shù)，設(shè)計(jì)并實(shí)現(xiàn)了核心邏輯流程與系統(tǒng)功能模塊。最后，通過綜合測(cè)試，驗(yàn)證了該系統(tǒng)在實(shí)時(shí)性、可靠性等方面的優(yōu)勢(shì)。

該地震預(yù)警信息發(fā)布系統(tǒng)具有如下特點(diǎn)：①兼容性，預(yù)警參數(shù)計(jì)算與各類數(shù)據(jù)源之間完全解耦，通過協(xié)議自動(dòng)適配，支持多類預(yù)警數(shù)據(jù)源的接入；②靈活性，系統(tǒng)基于服務(wù)組件架構(gòu)模型開發(fā)，各類用戶可根據(jù)需求最大化的配置、定制系統(tǒng)服務(wù)；③可靠性，利用專有信息傳送機(jī)制，有效降低了系統(tǒng)總體延時(shí)，確保預(yù)警信息發(fā)布的時(shí)效性和可靠性。面向大規(guī)?；ヂ?lián)網(wǎng)用戶應(yīng)用時(shí)，有較高實(shí)時(shí)性要求的混合架構(gòu)應(yīng)用系統(tǒng)，具有一定的實(shí)際應(yīng)用價(jià)值和參考借鑒意義。

當(dāng)發(fā)生較大地震時(shí)，震源區(qū)的通訊設(shè)施可能被損毀，震源區(qū)用戶將無法接收到地震預(yù)警信息，因此，系統(tǒng)仍有改進(jìn)的空間。在接下來的工作中，將增加C/S架構(gòu)下桌面端信息接收軟件，通過在客戶端離線緩存地理信息數(shù)據(jù)，降低系統(tǒng)對(duì)互聯(lián)網(wǎng)數(shù)據(jù)的依賴，提升系統(tǒng)的實(shí)時(shí)性。同時(shí)，進(jìn)一步優(yōu)化系統(tǒng)架構(gòu)，增加廣播、衛(wèi)星等通訊方式，確保在互聯(lián)網(wǎng)中斷的極端情況下，仍能快速發(fā)布預(yù)警信息，增強(qiáng)系統(tǒng)的魯棒性。

致謝：感謝審稿專家對(duì)本文提出的修改建議，使系統(tǒng)的架構(gòu)設(shè)計(jì)趨于合理，文章的邏輯性更加嚴(yán)密。