這個解決方法已經(jīng)定制下來很久了，上一段時間比較忙，沒有時間整這些東西。最近稍微好些，不怎么加班。所以抽空總結(jié)下，同時也分享給大家，也算是給大家一個借鑒吧！或許這并不是最好的解決方案，但只要能滿足當(dāng)前需求的最好方案也算是最好的解決方案，誰說不是呢！O(∩_∩)O~

我們采用的方案如下：

先看圖

上圖的流程大致上是這樣的：

手機(jī)端向PC端發(fā)送聊天內(nèi)容

1、手機(jī)端程序通過Socket連接服務(wù)器端的ServerSocket

2、然后服務(wù)器端根據(jù)手機(jī)Mobile客戶端發(fā)送過來統(tǒng)一規(guī)范的報文或聊天內(nèi)容，進(jìn)行解析

3、然后將解析的內(nèi)容，再用smack框架轉(zhuǎn)發(fā)到openfire服務(wù)器

4、最后由openfire服務(wù)器向客戶端（BS、CS、PhoneClient）程序發(fā)送聊天信息。這里的客戶端可以是pc上的瀏覽器，pc上的桌面應(yīng)用，手機(jī)應(yīng)用等

5、PC客戶端BS程序（用http bind方式監(jiān)聽）的長連接監(jiān)聽到openfire服務(wù)器發(fā)送過來的數(shù)據(jù)，直接在頁面中顯示

同樣，PC客戶端向手機(jī)端發(fā)送聊天內(nèi)容

1、PC客戶端（BS）可以直接用http bind（xmpp 提供的http請求的長連接方式）直接向openfire服務(wù)器發(fā)送聊天數(shù)據(jù)；

2、然后openfire服務(wù)器接收到聊天內(nèi)容的時候，這時候socket服務(wù)器中的smack框架中有一個聊天內(nèi)容的監(jiān)聽器

3、監(jiān)聽到PC端向openfire發(fā)送的內(nèi)容后，會用socket的流向手機(jī)端發(fā)送我們定義好的報文或是聊天內(nèi)容

4、手機(jī)端的socket會不停的輪詢（可以模擬心跳式長連接的方式），判斷是否有消息到達(dá)，如果有則顯示

而普通的聊天程序的流程則是客戶端發(fā)送信息到openfire服務(wù)器，openfire服務(wù)器再將消息轉(zhuǎn)發(fā)給其他客戶端。他們省去了socket服務(wù)器這部分，那我們?yōu)槭裁匆由蟬ocket服務(wù)器這部分呢？

我們這樣做也是有自己的道理的：

首先，如果讓手機(jī)端自己實(shí)現(xiàn)向openfire服務(wù)器發(fā)送程序的代碼，那工作量是相當(dāng)大的。因為每個手機(jī)平臺使用的語言都不同，每個平臺都需要實(shí)現(xiàn)向openfire服務(wù)器發(fā)送聊天信息的報文。這其實(shí)就是在做重復(fù)的工作，而且每個平臺實(shí)現(xiàn)向手機(jī)端發(fā)送報文信息的技術(shù)會讓每個手機(jī)端的開發(fā)人員都要學(xué)會一套和openfire交互的代碼。這勢必會重復(fù)工作、重復(fù)相同業(yè)務(wù)的代碼。所以，把這些代碼放在一個tcp/ip的socket中轉(zhuǎn)服務(wù)器進(jìn)行統(tǒng)一發(fā)送，這也是有好處的。

其次，把所以發(fā)送消息在報文在socket服務(wù)器完成，可以對業(yè)務(wù)進(jìn)行一個統(tǒng)一的處理、消息過濾。

手機(jī)端被否決的解決方案，供參考

手機(jī)端用http長連接的方式，這個是不行的

其一、手機(jī)的移動網(wǎng)絡(luò)不穩(wěn)定，長連接會經(jīng)常斷掉，當(dāng)然你可以自動進(jìn)行重連

其二、長連接一直連接在服務(wù)器上，占用服務(wù)器資源。當(dāng)然你可以使用心跳式長連接或是輪詢方式

其三、手機(jī)端一直連接服務(wù)器會使用手機(jī)端用戶的網(wǎng)絡(luò)帶寬流量（流量不是免費(fèi)的，客戶會怎么想）

其四、手機(jī)端一直連著服務(wù)器，對手機(jī)的電量也有消耗（現(xiàn)在智能機(jī)解決電量也是一個問題）

版權(quán)所有，歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明出處，謝謝