引 言

隨著人們逐漸從PC 解放，需求開始轉(zhuǎn)移到移動(dòng)設(shè)備的應(yīng)用上。目前福建地區(qū)的小區(qū)住戶、物業(yè)和周邊配套服務(wù)都還處于離散狀態(tài)，人們迫切希望有一款基于移動(dòng)設(shè)備的智能社區(qū)服務(wù)平臺，可以通過該系統(tǒng)方便住戶隨時(shí)獲取小區(qū)的重要資訊， 了解住宅的實(shí)時(shí)情況，監(jiān)控和控制住宅內(nèi)的電器設(shè)備。而小區(qū)周邊的其他配套服務(wù)系統(tǒng)可以通過該平臺提供的接口直接與平臺對接，向住戶提供服務(wù)。

1 系統(tǒng)設(shè)計(jì)原理圖

本系統(tǒng)建立在J2EE 平臺上，運(yùn)用 MySQL 數(shù)據(jù)庫管理系統(tǒng)將 JSON 解析與 Netty、WebSocket 等技術(shù)相結(jié)合，構(gòu)建更加智能的社區(qū)增值服務(wù)平臺。社區(qū)增值服務(wù)系統(tǒng)搭建在云平臺之上，充分利用現(xiàn)代化信息技術(shù)手段實(shí)現(xiàn)社區(qū)管理及服務(wù)的信息化、集約化，依托云平臺的理念和優(yōu)勢，將已有的專業(yè)系統(tǒng)納入其中，為社區(qū)居民、物業(yè)管理、周邊服務(wù)機(jī)構(gòu)提供便利豐富的終端服務(wù)。系統(tǒng)設(shè)計(jì)原理圖如圖 1 所示。

該平臺的亮點(diǎn)是信息的分類推送，開發(fā)之前對信息推送的兩種方式進(jìn)行分析： 

（1）第一種是客戶端使用 Pull（拉）的方式，即定時(shí)到服 務(wù)器上獲取，看是否有更新的信息。 

（2）第二種是服務(wù)器使用 Push（推送）的方式，把最新 的信息 Push 到客戶端上。 

雖然 Pull 和 Push 兩種方式都能實(shí)現(xiàn)獲取服務(wù)端更新信 息的功能，但 Push 方式比 Pull 方式更優(yōu)越 [1，2]。 

本文通過對比分析國內(nèi)現(xiàn)有的移動(dòng)設(shè)備推送解決方案， 采用 Netty+WebSocket 持久連接的方式，實(shí)現(xiàn)了消息的實(shí)時(shí) 性推送和分類推送。

2 推送與控制實(shí)現(xiàn)

平臺可實(shí)現(xiàn)系統(tǒng)用戶的需求，如查看家中的光照強(qiáng)度、室內(nèi)溫度、空氣濕度、煙霧濃度等實(shí)時(shí)數(shù)據(jù)，并對家中的家居進(jìn)行控制操作，對硬件與手機(jī)之間的鏈接通信進(jìn)行了詳細(xì)合理的設(shè)計(jì)。Netty 與WebSocket 的結(jié)合完美解決了此通路問題，為實(shí)現(xiàn)平臺的實(shí)時(shí)推送和分類推送奠定了基礎(chǔ)。

(1) NettyServer集成了WebSocketClient，用來實(shí)現(xiàn)與各硬件之間的數(shù)據(jù)傳送，NettyServer在初始化時(shí)與WebSocket Server建立長鏈接；

(2) WebSocketServer實(shí)現(xiàn)了與集成在 Netty服務(wù)器中的WebSocketClient之間的數(shù)據(jù)傳送以及與用戶手機(jī)端（或網(wǎng)頁） 的交互。

推送和控制詳細(xì)設(shè)計(jì)原理圖如圖 2 所示。

平臺將傳感器的數(shù)據(jù)推送到用戶的流程描述 ：單片機(jī)采集各傳感器的實(shí)時(shí)數(shù)據(jù)，將這些數(shù)據(jù)通過 TCP上傳到Netty 服務(wù)器， 當(dāng)TCP 與 Netty 服務(wù)器第一次建立連接時(shí)， 觸發(fā)channelActive() 方法建立通道，該通道在傳感器斷開之前一直存在，此后傳感器定時(shí)發(fā)送數(shù)據(jù)，并直接觸發(fā)channelRead0() 方法接收， 接收到的數(shù)據(jù)由集成在本服務(wù)器的WebSocket Client 模塊處理， 通過 WebSocketClient.send() 方法發(fā)送給WebSocket 服務(wù)器，WebSocket 服務(wù)器中的WebSocket Server 通過onMessage() 方法接收，接收到實(shí)時(shí)數(shù)據(jù)后，則由 client. session.getBasicRemote().sendText(msg) 將數(shù)據(jù)推送給手機(jī)或網(wǎng)頁終端。

Netty 服務(wù)器采用多線程服務(wù)器，對于每一個(gè)連接請求， dispatcher 都會為其創(chuàng)建并分配一個(gè)線程，該線程負(fù)責(zé)這個(gè)請求的處理，優(yōu)點(diǎn)是執(zhí)行粒度是完整的處理流程，處理邏輯清晰，易于開發(fā)。但也存在隨著處理請求的不斷增加，會導(dǎo)致并發(fā)執(zhí)行的線程數(shù)量太多等問題。過多的線程數(shù)量會導(dǎo)致系統(tǒng)在線程調(diào)度和資源爭用上的開銷過大，從而引起系統(tǒng)性能急劇下降，導(dǎo)致系統(tǒng)處理能力下降。該平臺采用了改進(jìn)措施， 引入線程池，系統(tǒng)最多只能創(chuàng)建一定數(shù)量的線程，該平臺規(guī)定最多能創(chuàng)建的線程數(shù)量為 100。當(dāng)所有線程都飽和運(yùn)行時(shí)，新到達(dá)的處理請求只能等待或者被拋棄。

在實(shí)現(xiàn)WebSocket的鏈接過程中，客戶端和普通的瀏覽器都通過 80 或者 443端口和服務(wù)器進(jìn)行請求握手，服務(wù)器根據(jù) httpheader識別是否是一個(gè)WebSocket請求，如果是， 則將請求升級為一個(gè)WebSocket連接，握手成功后就進(jìn)入雙向長連接的數(shù)據(jù)傳輸階段。WebSocket的數(shù)據(jù)傳輸基于幀方式：0x00表示數(shù)據(jù)開始，0xff表示數(shù)據(jù)結(jié)束，數(shù)據(jù)以utf-8 編碼。第一次請求客戶端發(fā)送的是http請求，請求頭中包含WebSocket相關(guān)的信息，服務(wù)器端對請求進(jìn)行驗(yàn)證，驗(yàn)證成功后，將請求升級為一個(gè)WebSocket連接，之后的通信就進(jìn)入雙向長連接的數(shù)據(jù)傳輸階段，通過send和onMessage方法通信。

2.2 分類推送

平臺采用 WebSocket 協(xié)議不僅實(shí)現(xiàn)了 Netty 服務(wù)器與WebSocket 服務(wù)器的實(shí)時(shí)通信，在分類通信上也做了一定嘗試， 如推送工作，推送給哪一類型的用戶，可以根據(jù)數(shù)據(jù)的格式來進(jìn)行劃分，在本平臺中只做了初步劃分，如數(shù)據(jù)格式為：{"from":"SMSG","room":"1201","temperature":"1","humidity":"2

.0","smoke?":"3"}（JSON形式）， 從 room字段可以知道該數(shù)據(jù)是準(zhǔn)備傳送給 1201室的用戶，目前平臺只做了這個(gè)分類， 平臺的下一步工作將在數(shù)據(jù)的格式上進(jìn)行進(jìn)一步細(xì)化和分類， 如按不同的樓棟，甚至不同的樓層分類，在分類推送上完善平臺的功能。

2.3 JSON格式通信

JSON是一種輕量級數(shù)據(jù)交換格式，它采用完全獨(dú)立于語言的文本格式，此特性使JSON成為理想的數(shù)據(jù)交換語言， 易于閱讀和編寫，同時(shí)也易于機(jī)器解析和生成，提升網(wǎng)絡(luò)傳輸速率。本平臺的各數(shù)據(jù)通信環(huán)節(jié)均采用JSON格式通信，使用對象和數(shù)組兩種結(jié)構(gòu)。對象在JSON格式表示為 { } 中的內(nèi)容，數(shù)組在JSON格式是中括號 [ ] 中的內(nèi)容，通過這兩種結(jié)構(gòu)可以表示各種復(fù)雜的結(jié)構(gòu)[3]。

例如在 Netty 服務(wù)器將這些數(shù)據(jù)組織成 JSON 格式：{ "from":"SMSG","room":"1201","temperature":"1","humidity":"2.0","smoke?":"3"}，WebSocketServe接收到數(shù)據(jù)后根據(jù)數(shù)據(jù)的格式進(jìn)行判斷，該數(shù)據(jù)由Netty服務(wù)器發(fā)送過來，可立即根據(jù)room找到對應(yīng)的目標(biāo)用戶，讀取其中的溫度、濕度和煙霧值， 并推送數(shù)據(jù)。

2.4 控制實(shí)現(xiàn)

當(dāng)用戶發(fā)送控制信息時(shí)，數(shù)據(jù)又是如何從手機(jī)終端到達(dá)控制設(shè)備的呢？這個(gè)流程和 2.1 中介紹的推送流程相反。值得一提的是，WebSocket 服務(wù)器中的 WebSocket Server 通過onMessage() 方法接收， 接收的數(shù)據(jù)有可能是 Netty 服務(wù)器或手機(jī)終端發(fā)送的，WebSocket Serve 接收到數(shù)據(jù)后根據(jù)數(shù)據(jù)的格式進(jìn)行判斷， 根據(jù)不同的要求往不同的目標(biāo)發(fā)送， 都由client.session.getBasicRemote().sendText(msg) 完成， WebSocket 服務(wù)器在推送和控制的過程中充當(dāng)了一個(gè)重要的轉(zhuǎn)接角色。

3 Android客戶端設(shè)計(jì)

3.1 Service組件

在Android 中使用Service 服務(wù)組件作為通信服務(wù)層的組件。Service 服務(wù)運(yùn)行于應(yīng)用程序的后臺，適合運(yùn)行長期執(zhí)行的操作。為了實(shí)現(xiàn)消息的及時(shí)接收，需要將 WebSocket 通信模塊放在后臺服務(wù)中運(yùn)行，這樣當(dāng)應(yīng)用程序被置于屏幕后臺運(yùn)行時(shí)（如此時(shí)打開了其他應(yīng)用程序），仍然能在后臺接收到服務(wù)器發(fā)送的消息并通知用戶處理[4]。

Android 客戶端設(shè)計(jì)的通信服務(wù)組件CommunicationService 繼承自Android 系統(tǒng)的 Service 組件， 并重寫它的 OnBind， OnCreate，OnStart 和OnDestroy 等方法。

(1) OnBind：將當(dāng)前服務(wù)器實(shí)例返回給綁定服務(wù)的組件， 如Application。

(2) OnCreate：讀取應(yīng)用程序上下文，并廣播消息告知服務(wù)已經(jīng)啟動(dòng)。

(3) OnStart：判斷客戶端是否通過身份認(rèn)證， 若是， 則在尚未連接的條件下與通信服務(wù)器進(jìn)行連接，此處使用WebSocket客戶端對象來與系統(tǒng)通信服務(wù)器建立連接， 實(shí)現(xiàn)消息的發(fā)送和接收， 在 WebSocketClient.Handler實(shí)例中重寫onMessage方法以實(shí)現(xiàn)對接收到的消息進(jìn)行處理。當(dāng)WebSocket客戶端接收到來自服務(wù)器的消息時(shí)，首先通過消息模型MessageModel的parse方法將文本消息轉(zhuǎn)換為消息對象， 并根據(jù)消息類型調(diào)用消息處理模塊MessageHandle的對應(yīng)方法對消息進(jìn)行進(jìn)一步處理，同時(shí)傳入OnMessageListener接口， 將消息模型傳遞給UI層進(jìn)行必要的處理。

(4) OnDestroy：關(guān)閉與通信服務(wù)器的鏈接，釋放資源。

3.2  Android客戶端效果圖

Android 客戶端設(shè)計(jì)效果圖如圖 3 所示。

4 結(jié) 語

本平臺使用Netty+WebSocket 技術(shù)解決了移動(dòng)設(shè)備與后臺服務(wù)器雙向通訊的問題，后臺可以隨時(shí)向用戶推送消息，以保證前后臺狀態(tài)統(tǒng)一，在傳統(tǒng)的HTTP 協(xié)議中，這是很難實(shí)現(xiàn)的，下一步工作將在數(shù)據(jù)格式上進(jìn)行進(jìn)一步細(xì)化和分類，將分類和實(shí)時(shí)推送做到最優(yōu)。