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

我們采用的方案如下：

先看圖

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

手機端向PC端發送聊天內容

1、手機端程序通過Socket連接服務器端的ServerSocket

2、然后服務器端根據手機Mobile客戶端發送過來統一規范的報文或聊天內容，進行解析

3、然后將解析的內容，再用smack框架轉發到openfire服務器

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

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

同樣，PC客戶端向手機端發送聊天內容

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

2、然后openfire服務器接收到聊天內容的時候，這時候socket服務器中的smack框架中有一個聊天內容的監聽器

3、監聽到PC端向openfire發送的內容后，會用socket的流向手機端發送我們定義好的報文或是聊天內容

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

而普通的聊天程序的流程則是客戶端發送信息到openfire服務器，openfire服務器再將消息轉發給其他客戶端。他們省去了socket服務器這部分，那我們為什么要加上socket服務器這部分呢？

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

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

其次，把所以發送消息在報文在socket服務器完成，可以對業務進行一個統一的處理、消息過濾。

手機端被否決的解決方案，供參考

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

其一、手機的移動網絡不穩定，長連接會經常斷掉，當然你可以自動進行重連

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

其三、手機端一直連接服務器會使用手機端用戶的網絡帶寬流量（流量不是免費的，客戶會怎么想）

其四、手機端一直連著服務器，對手機的電量也有消耗（現在智能機解決電量也是一個問題）

版權所有，歡迎轉載，轉載請注明出處，謝謝