基于Android的智能可視化指揮系統(tǒng)

廖列法，張幸平

(江西理工大學(xué) 信息工程學(xué)院，江西 贛州 341000)

0 引 言

隨著人工智能時(shí)代的來(lái)臨以及Android智能設(shè)備的普及，針對(duì)移動(dòng)端的應(yīng)用越來(lái)越廣泛，移動(dòng)設(shè)備上的應(yīng)用技術(shù)已成為當(dāng)前科技領(lǐng)域熱門的研究方向。傳統(tǒng)的指揮系統(tǒng)中要求使用專用設(shè)備，比如對(duì)講機(jī)、照相機(jī)、GPS等，對(duì)設(shè)備要求性較高、負(fù)擔(dān)較大。與此同時(shí)，支持的功能和使用界面較為簡(jiǎn)單，沒(méi)有良好的用戶體驗(yàn)感，無(wú)法滿足日益增長(zhǎng)的用戶需求。近些年智能指揮類系統(tǒng)在各行各業(yè)都有不斷的被提出及應(yīng)用，比如基于Android的應(yīng)急指揮系統(tǒng)[1]、調(diào)度指揮系統(tǒng)[2]、扁平化的圖形類指揮系統(tǒng)[3]等，但這些系統(tǒng)主要還是采用傳統(tǒng)的Client/Server技術(shù)，系統(tǒng)架構(gòu)部署較為復(fù)雜，對(duì)服務(wù)器要求較高。因此基于當(dāng)前主流的Spring Cloud[4]微服務(wù)架構(gòu)體系實(shí)現(xiàn)一套滿足云服務(wù)器下分布式集群化的輕量型實(shí)時(shí)可視化指揮系統(tǒng)具有非常重要的應(yīng)用與研究?jī)r(jià)值。

本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于Android的智能可視化指揮系統(tǒng)。為了滿足大用戶、高并發(fā)、可擴(kuò)展的部署需求，該系統(tǒng)采用了采用Spring Cloud微服務(wù)架構(gòu)和Ngnix[5]、Redis[6]、Nodejs[7]、Mysql[8]等技術(shù)。采用3種定位技術(shù)(網(wǎng)絡(luò)[9]、GPS[10]和離線[11])來(lái)保證用戶位置的實(shí)時(shí)獲取，設(shè)計(jì)用戶上下消息、語(yǔ)音控制類消息，通過(guò)自主的實(shí)時(shí)傳輸協(xié)議實(shí)現(xiàn)信息的實(shí)時(shí)傳輸，同時(shí)以地圖為基本元素，展示可視化指揮的所有功能。既增強(qiáng)了傳統(tǒng)指揮系統(tǒng)的功能，實(shí)現(xiàn)了直觀、可視化的展現(xiàn)方式，又提供了一套輕量型的實(shí)時(shí)可視化指揮系統(tǒng)方案。

1 系統(tǒng)方案設(shè)計(jì)

方案設(shè)計(jì)的基本要求是支持在多臺(tái)云服務(wù)器上進(jìn)行分布式和集群化的部署，以保證所開(kāi)發(fā)系統(tǒng)的穩(wěn)定性、可靠性和可擴(kuò)展性。接下來(lái)，我們將從系統(tǒng)的組織框架、整體架構(gòu)和功能架構(gòu)進(jìn)行具體介紹。

1.1 系統(tǒng)組織架構(gòu)

在Spring Cloud微服務(wù)的框架下，根據(jù)不同的功能，設(shè)計(jì)的功能服務(wù)模塊包括音頻服務(wù)(Audi)、上下線服務(wù)(Online)、轉(zhuǎn)發(fā)服務(wù)(Forward)、消息通知服務(wù)(Notification)，以及線程池同步服務(wù)。其中音頻服務(wù)模塊提供了視頻和音頻消息的相關(guān)接口，上線下服務(wù)模塊提供了用戶狀態(tài)的相關(guān)接口，轉(zhuǎn)發(fā)服務(wù)模塊提供了消息的轉(zhuǎn)發(fā)接口，消息通知服務(wù)模塊提供了通知的相關(guān)接口，線程池同步服務(wù)模塊提供了不同線程之間數(shù)據(jù)的同步。根據(jù)消息的類型，該系統(tǒng)設(shè)計(jì)的消息類型分為聊天文本、消息類文本(同步消息、下線消息、推送消息和通知消息)、圖像、視頻流、語(yǔ)音流等。圖1展示了如上所述的系統(tǒng)組織架構(gòu)。

圖1 系統(tǒng)組織框架

1.2 系統(tǒng)整體架構(gòu)

該系統(tǒng)涉及的主要模塊包括2個(gè)消息通知服務(wù)(notify server1和server2)、緩存服務(wù)(Redis)、消息服務(wù)進(jìn)程(接收和轉(zhuǎn)發(fā))、通知推送服務(wù)平臺(tái)(包含自主和第三方的消息推送服務(wù))、Android移動(dòng)端等。其中，所有加入的移動(dòng)客戶端都會(huì)與消息通知服務(wù)器建立連接，而負(fù)載均衡模塊負(fù)責(zé)分配新加入設(shè)備需要連接的服務(wù)器。具體來(lái)說(shuō)，消息的發(fā)生到接收會(huì)涉及以下過(guò)程。首先，消息發(fā)送到消息通知服務(wù)器；其次，消息通知服務(wù)將消息以異步的方式存入數(shù)據(jù)庫(kù)和緩存(Redis)中；第三，查詢目標(biāo)用戶連接的服務(wù)器；第四，將消息轉(zhuǎn)發(fā)到上一步查詢到的服務(wù)器中；最后，接收到消息的服務(wù)器將數(shù)據(jù)推送到相應(yīng)的客戶端。圖2顯示了整個(gè)系統(tǒng)的架構(gòu)和消息流轉(zhuǎn)。

圖2 系統(tǒng)架構(gòu)

1.3 系統(tǒng)功能架構(gòu)

系統(tǒng)采用C/S架構(gòu)，客戶端與服務(wù)器之間通過(guò)TCP協(xié)議通信。服務(wù)器提供的功能包括數(shù)據(jù)的持久化存儲(chǔ)(數(shù)據(jù)庫(kù))、語(yǔ)音流和視頻流數(shù)據(jù)的實(shí)時(shí)傳輸、文本類消息的實(shí)時(shí)中轉(zhuǎn)(即時(shí)文本、位置類、控制類和狀態(tài)類消息)。同時(shí)以Nginx為負(fù)載均衡反向代理服務(wù)，Redis為主從的集群方案，Nodejs為應(yīng)用服務(wù)器，Mysql為數(shù)據(jù)存儲(chǔ)服務(wù)來(lái)提供一套高可用、高并發(fā)的集群化解決方案。

客戶端提供的功能包括良好的使用界面、流數(shù)據(jù)的處理(如，發(fā)送、接收、解析和播放)、文本數(shù)據(jù)的處理(如，即時(shí)文本、位置類、控制類和狀態(tài)類等消息的解析和轉(zhuǎn)發(fā))，以及用戶位置的實(shí)時(shí)獲獲取、轉(zhuǎn)發(fā)和解析。圖3展示了該系統(tǒng)的功能架構(gòu)。

圖3 系統(tǒng)功能架構(gòu)

如圖3所示，客戶端支持的設(shè)備為Android的移動(dòng)端和PAD端(系統(tǒng)版本號(hào)為4.0以上)。根據(jù)功能劃分，客戶端首先會(huì)連接Nginx服務(wù)器。該服務(wù)器作為負(fù)載均衡模塊，它將根據(jù)權(quán)重配比將所有請(qǐng)求進(jìn)行隨機(jī)分發(fā)，以確保動(dòng)靜分離。其次，所有的交互數(shù)據(jù)將會(huì)由相應(yīng)的Nodjs服務(wù)器進(jìn)行處理。該服務(wù)器作為數(shù)據(jù)處理的核心模塊，它將根據(jù)事件類型，通過(guò)異步的方式進(jìn)行高效的數(shù)據(jù)傳送，以實(shí)現(xiàn)不同終端之間的數(shù)據(jù)交互。最后，為了保證數(shù)據(jù)的高速存取，臨時(shí)存儲(chǔ)的Session數(shù)據(jù)(如，會(huì)話狀態(tài)數(shù)據(jù))存入緩存服務(wù)模塊(Redis)，以實(shí)現(xiàn)Nodejs服務(wù)器之間的數(shù)據(jù)共享。永久性存儲(chǔ)的數(shù)據(jù)則存入數(shù)據(jù)庫(kù)模塊(Mysql)，非永久性存儲(chǔ)且常訪問(wèn)的數(shù)據(jù)則存入內(nèi)存模塊中。

2 系統(tǒng)軟件設(shè)計(jì)

2.1 服務(wù)器軟件設(shè)計(jì)

服務(wù)器是整個(gè)系統(tǒng)的數(shù)據(jù)中轉(zhuǎn)和處理中心。圖4展示了整個(gè)數(shù)據(jù)的處理流程。當(dāng)服務(wù)器收到支持的所有消息(用戶上線和下線、語(yǔ)音流數(shù)據(jù)、實(shí)時(shí)位置、麥空閑狀態(tài)、鎖麥狀態(tài)等)等數(shù)據(jù)時(shí)直接透?jìng)鞯较到y(tǒng)中所有在線的用戶。收到搶麥消息時(shí)查詢用戶的信息，如果用戶具有管理員權(quán)限，則進(jìn)入強(qiáng)制搶麥模式，若當(dāng)前有人正在說(shuō)話，則將用戶踢下保證搶麥的成功，同時(shí)將搶麥成功消息回調(diào)給用戶，如果用戶是普通權(quán)限，則進(jìn)入正常搶麥模式，若當(dāng)前有人正在說(shuō)話，則搶麥?zhǔn)?，相反則搶麥成功，同時(shí)將搶麥結(jié)果消息回調(diào)給用戶。

圖4 服務(wù)器數(shù)據(jù)流程

2.2 客戶端軟件設(shè)計(jì)

客戶端主要包括登錄和可視化對(duì)講兩個(gè)模塊，其功能流程如圖5所示，圖5中，用戶在登錄界面填寫用戶名、密碼、房間名、服務(wù)器地址等信息與服務(wù)器建立連接，完成登錄操作。登錄成功后則進(jìn)入對(duì)講主界面，此模塊主要包含用戶位置信息、對(duì)講功能、搶麥功能的展示。其中位置信息的展示主要包含用戶上下線時(shí)動(dòng)態(tài)的增加或刪除用戶、更新用戶列表，用戶位置發(fā)生變化時(shí)，在地圖上動(dòng)態(tài)改變用戶的位置坐標(biāo)。對(duì)講功能主要包含語(yǔ)音流數(shù)據(jù)的采集、編碼、轉(zhuǎn)發(fā)和語(yǔ)音流數(shù)據(jù)的接收、轉(zhuǎn)碼和播放。搶麥功能首先是發(fā)送搶麥指令到服務(wù)器。如果服務(wù)器返回成功的狀態(tài)，則開(kāi)始實(shí)時(shí)語(yǔ)音對(duì)講流程，對(duì)語(yǔ)音流數(shù)據(jù)進(jìn)行實(shí)時(shí)的采集和編碼轉(zhuǎn)發(fā)、接收和解碼播放。相反，如果搶麥?zhǔn)?，則在界面上顯示相關(guān)提示信息。

圖5 客戶端功能流程

3 技術(shù)挑戰(zhàn)及解決方法

數(shù)據(jù)傳送的實(shí)時(shí)性和可靠性是整個(gè)系統(tǒng)的關(guān)鍵，而涉及的主要數(shù)據(jù)是實(shí)時(shí)獲取的用戶定位信息和實(shí)時(shí)采集的語(yǔ)音流消息。因此，如何確保傳輸這些數(shù)據(jù)的效率和穩(wěn)定性該系統(tǒng)面臨的主要挑戰(zhàn)。簡(jiǎn)單來(lái)說(shuō)，需要滿足的基本要求是：終端用戶將大量的位置消息和語(yǔ)音流數(shù)據(jù)進(jìn)行封裝，經(jīng)服務(wù)器處理和中轉(zhuǎn)，到達(dá)指定的目標(biāo)用戶后，實(shí)時(shí)的在終端設(shè)備上進(jìn)行實(shí)時(shí)的解碼、界面展示和語(yǔ)音播放。

3.1 音頻的采集與播放

(1)音頻流的采集

通過(guò)調(diào)用原生API(AudioRecord)采集音頻流數(shù)據(jù)，采集參數(shù)分別為音頻源(MediaRecorder.AudioSource.MIC)、采樣率(16 000 Hz)、音頻通道(單通道：CHANNEL_IN_MONO)、音頻格式(16位：ENCODING_PCM_16Bit)。整個(gè)音頻流的采集過(guò)程主要包括以下步驟：第一步，通過(guò)上面的初始化參數(shù)建立AudioRecord對(duì)象。第二步，開(kāi)啟一個(gè)AudioCollectionThread線程，在該線程中采集音頻流數(shù)據(jù)，并調(diào)用回調(diào)函數(shù)接口(sendAudioFrame)。第三步，在回調(diào)函數(shù)sendAudioFrame中，利用Speex[12]對(duì)語(yǔ)音流數(shù)據(jù)進(jìn)行編碼后，再將封裝的數(shù)據(jù)傳輸?shù)椒?wù)器。這一過(guò)程涉及的主要代碼如下：

collectionRecord = new AudioRecord(collectionSource, collectionRateInHz, collectionChannel, collectionFormat, readBufferSize);

@Override

public void run() {

while (!isNeedExit) {

byte[] readBuffer = new byte[readBufferSize];

int count = collectionRecord.read(readBuffer, 0, readBufferSize);

onAudioFrameListener.sendAudioFrame(readBuffer, readBufferSize);

}

(2)音頻流的解碼和播放

首先是音頻流數(shù)據(jù)的解碼。解碼方式與采集方式相似，使用的是系統(tǒng)的另一個(gè)API(AudioTrack)。解碼接口的傳入?yún)?shù)與采集時(shí)的參數(shù)一致，分別為16 000 Hz、單通道、16位。整個(gè)音頻流的解碼和播放過(guò)程主要包括以下步驟：第一步，通過(guò)上面的初始化參數(shù)建立AudioTrack對(duì)象。第二步，開(kāi)啟一個(gè)AudioDecodeThread線程，在該線程中接收音頻流數(shù)據(jù)。第三步，利用Speex對(duì)語(yǔ)音流數(shù)據(jù)進(jìn)行解碼后，再將獲得的原始音頻流數(shù)據(jù)寫入AudioPlayTrack進(jìn)行播放。這一過(guò)程涉及的主要代碼如下：

audioPlayTrack = new AudioPlayTrack(dataType, da-taRateInHz, dataChannel, dataFormat,

dataBufferSize, PLAY_AUDIO_MODE);

@Override

public void run() {

while (needPlaying) {

int readSize = ReceiveAudioStreamLib.receive_play_pcm(AudioStreamUtils.receive_steam, readBuffer, dataBufferSize);

if (readSize > 0) {

audioPlayTrack.write(readBuffer, 0, readSize);

}

}

}

3.2 位置的實(shí)時(shí)展示

通過(guò)百度地圖Android SDK[13]進(jìn)行位置展示和定位，使用的參數(shù)分別為高精度模式(ParamHightAccuracy)、gcj02坐標(biāo)系、1 s的間隔頻率，并開(kāi)啟GPS、室內(nèi)定位。整個(gè)過(guò)程通過(guò)注冊(cè)監(jiān)聽(tīng)回調(diào)接口的方式完成。首先，通過(guò)上述的初始化參數(shù)進(jìn)行接口的注冊(cè)。其次，注冊(cè)成功后，終端設(shè)備上用戶的位置變化會(huì)實(shí)時(shí)反饋到receiveDecive-Location函數(shù)。最后，對(duì)每次收到的位置信息進(jìn)行解析，若用戶位置發(fā)生了變化，則通過(guò)AudioStreamUtils.send-CustomDataToServer函數(shù)發(fā)送到目標(biāo)用戶，并在終端設(shè)備的地圖上實(shí)施更新位置。這一過(guò)程涉及的主要代碼如下：

LocationClientOption locParam = currentLocClient.getLocOption();

locParam.setLocationMode(ParamHightAccuracy);

locParam.setCoorType("gcj02");

locParam.setLocationNotify(true);

currentLocClient.startIndoorMode();

currentLocClient.regDeviceLocationRecall(mRegDeviceLocationRecall);

@Override

public void receiveDeviceLocation(BDLocation currentLoc) {

AudioStreamUtils.sendCustomDataToServer(currentLoc);

}

當(dāng)位置消息到達(dá)服務(wù)器時(shí)，首先該服務(wù)器會(huì)檢索當(dāng)前在線的終端用戶，然后根據(jù)用戶列表將該消息透?jìng)鹘o每一個(gè)用戶。然后，終端用戶收到該消息時(shí)，則在終端設(shè)備的地圖上實(shí)施對(duì)應(yīng)用戶的位置。這一過(guò)程涉及的主要代碼如下：

其三，19世紀(jì)40年代的英國(guó)剛剛面臨第一次工業(yè)大蕭條，社會(huì)開(kāi)始騷亂，工人運(yùn)動(dòng)興起，社會(huì)思想家托馬斯·卡萊爾通過(guò)比較現(xiàn)在與過(guò)去，無(wú)情地揭露出新時(shí)代產(chǎn)生的種種弊端，并呼吁社會(huì)改造，這幫作為社會(huì)意識(shí)形態(tài)建構(gòu)組成部分的藝術(shù)創(chuàng)作群體樹(shù)立了明確的斗爭(zhēng)對(duì)象，即專橫的藝術(shù)體制。

@Override

public void receiveData(String data) {

dataUtils.updateDeviceFromCustomData(data);

}

3.3 自定義的消息傳輸協(xié)議

為了進(jìn)一步提高系統(tǒng)在多用戶使用場(chǎng)景下的并發(fā)能力和可用性，除了滿足分布式、集群化部署的架構(gòu)要求外，還設(shè)計(jì)了一套定制化的、輕巧的、高效的消息傳輸協(xié)議[14,15]。該協(xié)議庫(kù)底層采用C語(yǔ)言實(shí)現(xiàn)和封裝，然后再通過(guò)JNA(Java Native Access)調(diào)用的方式進(jìn)行訪問(wèn)。該協(xié)議庫(kù)的主要代碼如下：

(1)建立連接

AudioStreamUtils.connectServer(String deviceParam, String teamParam, String serverIP,int serverPort, int advancedFlag)

實(shí)現(xiàn)說(shuō)明：調(diào)用系統(tǒng)函數(shù)Socket建立與服務(wù)器的TCP連接，同時(shí)將deviceParam、teamParam、advancedFlag參數(shù)傳遞到服務(wù)器，參數(shù)說(shuō)明見(jiàn)表1。

表1 參數(shù)說(shuō)明

(2)斷開(kāi)連接

AudioStreamUtils.disconnectServer()

實(shí)現(xiàn)說(shuō)明：將Socket連接斷開(kāi)。

(3)請(qǐng)求麥

AudioStreamUtils.requestMic()

實(shí)現(xiàn)說(shuō)明：發(fā)送請(qǐng)求麥的消息到服務(wù)器。

(4)釋放麥

AudioStreamUtils.freeMic()

實(shí)現(xiàn)說(shuō)明：發(fā)送釋放麥的消息到服務(wù)器。

(5)發(fā)送音頻流數(shù)據(jù)

AudioStreamUtils.sendCollectionAudioData (byte[] audioData, int audioSize)

實(shí)現(xiàn)說(shuō)明：將音頻消息通過(guò)Socket發(fā)送到服務(wù)器，參數(shù)說(shuō)明見(jiàn)表2。

表2 參數(shù)說(shuō)明

(6)接收音頻流數(shù)據(jù)

AudioStreamUtils.getCollectionAudioData(int audioSize)

實(shí)現(xiàn)說(shuō)明：通過(guò)線程實(shí)時(shí)獲取Socket收到的音頻數(shù)據(jù)，再將音頻數(shù)據(jù)放入到音頻流處理模塊，參數(shù)說(shuō)明見(jiàn)表3。

表3 參數(shù)說(shuō)明

(7)發(fā)送定制化消息

AudioStreamUtils.sendCustomMessage(String customMessage)

實(shí)現(xiàn)說(shuō)明：將自定義消息通過(guò)Socket發(fā)送到服務(wù)器，參數(shù)說(shuō)明見(jiàn)表4。

表4 參數(shù)說(shuō)明

(8)注冊(cè)回調(diào)函數(shù)

AudioStreamUtils.registerAudioRecallEvent

實(shí)現(xiàn)說(shuō)明：定義回調(diào)接口并注冊(cè)回調(diào)函數(shù)，回調(diào)接口見(jiàn)表5。

表5 回調(diào)函數(shù)

回調(diào)參數(shù)見(jiàn)表6。

表6 回調(diào)函數(shù)的參數(shù)

消息格式見(jiàn)表7。

表7 消息格式說(shuō)明

支持的消息類型如下：

1)新用戶加入

cmdStatus=newEnter，表8列出了返回值。

表8 回調(diào)-新用戶加入

2)用戶申請(qǐng)麥

cmdStatus=grapMike，表9列出了返回值。

表9 回調(diào)-用戶申請(qǐng)麥

3)用戶結(jié)束麥

cmdStatus=releaseMike，表10列出了返回值。

表10 回調(diào)-用戶結(jié)束麥

4)轉(zhuǎn)發(fā)到指定用戶

cmdStatus=fwdUser，表11列出了返回值。

表11 回調(diào)-轉(zhuǎn)發(fā)到指定用戶

5)轉(zhuǎn)發(fā)到所有在線用戶

cmdStatus=fwdAllUser，表12列出了返回值。

表12 回調(diào)-轉(zhuǎn)發(fā)到所有在線用戶

4 系統(tǒng)評(píng)估和效果展示

為了評(píng)估系統(tǒng)的性能和穩(wěn)定性，首先在騰訊云上部署了該系統(tǒng)，采用的服務(wù)器配置如下：實(shí)例配置(CPU：2核，內(nèi)存：4 G)、操作系統(tǒng)(CentOS 7.8 64位)、公網(wǎng)帶寬(5 Mbps)、高性能云硬盤(1 T)。其次，客戶端類型采用了Android的移動(dòng)設(shè)備和PAD終端設(shè)備，涉及多個(gè)廠商不同系統(tǒng)版本的Android設(shè)備，比如華為的P40 Pro、小米的MIX4、三星的Note8、OPPO的R9、vivo的X80。

在當(dāng)前主流的品牌和系統(tǒng)上的測(cè)試結(jié)果如下。首先，客戶端中包含的人機(jī)交互界面能適配所測(cè)試的全部機(jī)型，具有良好的UI適配性。其次，在4G和Wifi網(wǎng)絡(luò)下，測(cè)試過(guò)程中未出現(xiàn)連接斷開(kāi)、數(shù)據(jù)延時(shí)、數(shù)據(jù)終端等異常情況，因此，在網(wǎng)絡(luò)較佳的情況下使用過(guò)程流暢。在網(wǎng)絡(luò)較弱或信號(hào)不穩(wěn)定的情況下(比如，電梯里)，客戶端能即時(shí)給出相應(yīng)提示，并能夠在網(wǎng)絡(luò)恢復(fù)后重新連接上服務(wù)器，恢復(fù)終端設(shè)備狀態(tài)和同步當(dāng)前在線設(shè)備和位置信息。由此說(shuō)明，客戶端的異常機(jī)制進(jìn)一步確保了客戶端的可用性。最后，由于可用于測(cè)試的Android移動(dòng)設(shè)備和PAD終端的數(shù)量有限，我們利用額外的自動(dòng)化測(cè)試工具對(duì)服務(wù)器的穩(wěn)定性和并發(fā)能力進(jìn)行了測(cè)試。表13從并發(fā)設(shè)備(數(shù)量)、文本消息(條)、CPU利用率、響應(yīng)時(shí)間(秒)等指標(biāo)進(jìn)行了總結(jié)。

表13 服務(wù)器的并發(fā)測(cè)試結(jié)果

如表13所示，并發(fā)設(shè)備數(shù)量從200增加到400，400增加到800，800增加到1600時(shí)，CPU利用率的變化分別為0.4%、0.6%、0.9%，說(shuō)明該服務(wù)器所需的系統(tǒng)資源較低，可認(rèn)為是一種輕量型服務(wù)器。與此同時(shí)，消息數(shù)量在200～1600之間時(shí)，服務(wù)器的響應(yīng)時(shí)間在0.59 s至0.72 s之間，進(jìn)一步表明了該服務(wù)器的消息處理能力。

最后，圖6～圖8展示了客戶端的用戶登錄界面和可視化對(duì)講界面(其它設(shè)備正在講話、當(dāng)前設(shè)備正在講話)的使用效果。

圖6 用戶登錄界面

圖7 可視化對(duì)講界面-有人正在說(shuō)話

圖8 可視化對(duì)講界面-正在說(shuō)話

圖7、圖8中，頂部會(huì)動(dòng)態(tài)顯示當(dāng)前在線的用戶，地圖上會(huì)標(biāo)注每個(gè)在線用戶的位置，點(diǎn)擊底部圓型按鈕可以發(fā)起對(duì)講，同時(shí)在所有終端設(shè)備的頂部欄實(shí)時(shí)提示當(dāng)前說(shuō)明的終端用戶。同樣，如果某一終端設(shè)備離線，所有終端設(shè)備上的頂部欄和地圖界面都會(huì)進(jìn)行實(shí)時(shí)更新。

5 結(jié)束語(yǔ)

隨著人工智能與移動(dòng)互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，針對(duì)Android智能設(shè)備的應(yīng)用越來(lái)越廣泛，在Android智能設(shè)備上實(shí)現(xiàn)一套可視化指揮系統(tǒng)，既能增強(qiáng)指揮系統(tǒng)的功能，又能提供多元化的界面展示，更好適應(yīng)互聯(lián)網(wǎng)時(shí)代用戶的需求。下一步的研究將在另一主流的iOS系統(tǒng)上實(shí)現(xiàn)相應(yīng)的指揮系統(tǒng)。