引 言

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

1 系統(tǒng)設計原理圖

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

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

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

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

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

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

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

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

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

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

推送和控制詳細設計原理圖如圖 2 所示。

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

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

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

2.2 分類推送

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

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

2.3 JSON格式通信

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

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

2.4 控制實現(xiàn)

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

3 Android客戶端設計

3.1 Service組件

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

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

(1) OnBind：將當前服務器實例返回給綁定服務的組件， 如Application。

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

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

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

3.2  Android客戶端效果圖

Android 客戶端設計效果圖如圖 3 所示。

4 結 語

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