安卓phpmysql消息推送的簡單介紹

本文目錄一覽：

• 1、怎麼實現服務器給android客戶端主動推送消息
• 2、如何在php後端及時推送消息給客戶端
• 3、php實現websocket實時消息推送
• 4、php+mysql 站內信功能怎麼設計更合理？
• 5、極光推中如何自定義jsp或者php頁面作為服務端進行Android消息推送

怎麼實現服務器給android客戶端主動推送消息

一、消息推送基礎

消息推送，就是在互聯網上通過定期傳送用戶需要的信息來減少信息過載的一項新技術。推送技術通過自動傳送信息給用戶，來減少用於網絡上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其定期推給用戶，幫助用戶高效率地發掘有價值的信息

當我們開發需要和服務器交互的移動應用時，基本上都需要和服務器進行交互，包括上傳數據到服務器，同時從服務器上獲取數據。

一般情況下，客戶端與服務器之間通訊客戶端是主動的，但這就存在一個問題就是一旦服務器數據有更新或者服務器要下發通知給客戶端只能等客戶端連接的時候才能實現。這種方式使消息失去了實時性。

如何使客戶端能夠實時的收到服務器的消息和通知，總體來說有兩種方式，第一種是客戶端使用Pull（拉）的方式，就是隔一段時間就去服務器上獲取一下信息，看是否有更新的信息出現。第二種就是 服務器使用Push（推送）的方式，當服務器端有新信息了，則把最新的信息Push到客戶端上。這樣，客戶端就能自動的接收到消息。 

雖然Pull和Push兩種方式都能實現獲取服務器端更新信息的功能，但是明顯來說Push方式比Pull方式更優越。因為Pull方式更費客戶端的網絡流量，更主要的是費電量，還需要我們的程序不停地去監測服務端的變化。  

二、幾種常見的解決方案實現原理

1）輪詢(Pull)方式：客戶端定時向服務器發送詢問消息，一旦服務器有變化則立即同步消息。

2）SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解服務器的命令，但這種方式一般用戶在經濟上很難承受。

3）持久連接(Push)方式：客戶端和服務器之間建立長久連接，這樣就可以實現消息的及時行和實時性。

三、消息推送解決方案概述

A、C2DM雲端推送方案

在Android手機平台上，Google提供了C2DM（Cloudto Device Messaging）服務。Android Cloud to Device Messaging (C2DM)是一個用來幫助開發者從服務器向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，允許服務器可以通知移動應用程序直接與服務器進行通信，以便於從服務器獲取應用程序更新和用戶數據。

該方案存在的主要問題是C2DM需要依賴於Google官方提供的C2DM服務器，由於國內的網絡環境，這個服務經常不可用。

B、MQTT協議實現Android推送

採用MQTT協議實現Android推送功能也是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，它是實現基於手機客戶端的消息推送服務器的理想解決方案。

wmqtt.jar 是IBM提供的MQTT協議的實現。我們可以從這裡（）下載該項目的實例代碼，並且可以找到一個採用PHP書寫的服務器端實現（）。

C、RSMB實現推送功能

Really Small Message Broker (RSMB) ，是一個簡單的MQTT代理，同樣由IBM提供，其查看地址是：。缺省打開1883端口，應用程序當中，它負責接收來自服務器的消息並將其轉發給指定的移動設備。SAM是一個針對MQTT寫的PHP庫。我們可以從這個地址下載它.

D、XMPP協議實現Android推送

Google官方的C2DM服務器底層也是採用XMPP協議進行的封裝。XMPP(可擴展通訊和表示協議)是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許因特網用戶向因特網上的其他任何人發送即時消息。

androidpn是一個基於XMPP協議的java開源Android push notification實現。它包含了完整的客戶端和服務器端。但也存在一些不足之處：

1） 比如時間過長時，就再也收不到推送的信息了。

2）性能上也不夠穩定。

3）如果將消息從服務器上推送出去，就不再管理了，不管消息是否成功到達客戶端手機上。

如果我們要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。

E、使用第三方平台

目前國內、國外有一些推送平台可供使用，但是涉及到收費問題、保密問題、服務質量問題、擴展問題等等，又不得不是我們望而卻步。

四、消息推送完美方案

綜合以上論述，在建立Android消息推送方面可謂方案多多，但每一款方案都有其優缺點。但無論如何，還是自己搭建一個推送平台是上策。因為你有、他有不如自己有。

舉個例子，在搭建自有推送平台上建議使用《某某Android消息推送組件》。該組不僅可以拿來即用，並且還可以提供源碼以便擴展，實現自己的特殊需求。

A、推送原理

Android消息推送組件基於XMPP協議實現Android推送。XMPP（可擴展通訊和表示協議）是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許因特網用戶向因特網上的其他任何人發送即時消息。

如何在php後端及時推送消息給客戶端

1 ajax輪詢 5秒一次查

2 高級點的ajax輪詢，每次20多秒，服務端用while+sleep控制讀取消息隊列，一旦有新消息，及時髮結束返回 （微信web就用這種）

3 webstock 去找找現有的php集成，東西比較多

php實現websocket實時消息推送

一、socket協議的簡介

WebSocket是什麼，有什麼優點

WebSocket是一個持久化的協議，這是相對於http非持久化來說的。應用層協議

舉個簡單的例子，http1.0的生命周期是以request作為界定的，也就是一個request，一個response，對於http來說，本次client與server的會話到此結束；而在http1.1中，稍微有所改進，即添加了keep-alive，也就是在一個http連接中可以進行多個request請求和多個response接受操作。然而在實時通信中，並沒有多大的作用，http只能由client發起請求，server才能返回信息，即server不能主動向client推送信息，無法滿足實時通信的要求。而WebSocket可以進行持久化連接，即client只需進行一次握手，成功後即可持續進行數據通信，值得關注的是WebSocket實現client與server之間全雙工通信，即server端有數據更新時可以主動推送給client端。

二、介紹client與server之間的socket連接原理

1、下面是一個演示client和server之間建立WebSocket連接時握手部分

2、client與server建立socket時握手的會話內容，即request與response

a、client建立WebSocket時向服務器端請求的信息

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket //告訴服務器現在發送的是WebSocket協議

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== //是一個Base64 encode的值，這個是瀏覽器隨機生成的，用於驗證服務器端返回數據是否是WebSocket助理

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

Origin:

b、服務器獲取到client請求的信息後，根據WebSocket協議對數據進行處理並返回，其中要對Sec-WebSocket-Key進行加密等操作

HTTP/1.1 101 Switching Protocols

Upgrade: websocket //依然是固定的，告訴客戶端即將升級的是Websocket協議，而不是mozillasocket，lurnarsocket或者shitsocket

Connection: Upgrade

Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= //這個則是經過服務器確認，並且加密過後的 Sec-WebSocket-Key,也就是client要求建立WebSocket驗證的憑證

Sec-WebSocket-Protocol: chat

3、socket建立連接原理圖：

三、PHP中建立websocket的過程講解

SocketService.php:

web.html:

php+mysql 站內信功能怎麼設計更合理？

這個功能，你可以參考微博的推送思路。

比如你關注了很多明星（千萬級大V），他們發的每條微博會進入到“我的首頁”。比如某個明星發了條微博abc，你在“我的首頁”里看到的”abc”並不是讀自明星微博個人的數據庫，而是來自“我的首頁”里一個專門的數據集合。

通俗的講，這個數據集合是完全屬於你個人的，你所關注的每個人，當他們發微博時，會同步“推送”到你自己個人的這個“數據集合”里。

那麼問題來了，千萬級大V，每發一條微博，就要同步推給千萬個粉絲，生成千萬條數據嗎？NO，微博根據用戶活躍度等一系列算法，將用戶分成不同梯隊，一批一批的推送，例如一個近30天都沒登錄過的用戶，自然就會被划到較遲推送的那一批里。這樣做是為了分流服務器負擔。

但不同產品對於數據設計有不同的思路，你這個公用一條站內信，我的建議是，建個公共站內信統一變量（例如letter=20160514），可以保存到用戶的cookies里。

當用戶訪問頁面時，程序首先將這個變量值和cookies里保存的變量對比，相同則略過，不同則進行讀取相應的公共站內信，保存到自己的“收件箱”里。

這樣可以使原本需要同步推給千萬用戶一條站內信的工作，由主動推送變成被動發送。用戶上線訪問了，對比、發送，這種工作顯然要大大減小了服務器壓力。

讀取消息也是，反饋生成一條數據寫到數據庫里就好了。

極光推中如何自定義jsp或者php頁面作為服務端進行Android消息推送

你可以以API的方式調用，具體操作如下：

1、andriod 建立一個 含 andoid機器和消息的API請求；

2、ASP 或者 PHP 服務端請求jpush，根據返回結果輸出給API，可以參考jpush API v3案例：