參考消息推送

㈠ 如何實現消息推送功能

在開發Android和iPhone應用程序時，我們往往需要從伺服器不定的向手機客戶端即時推送各種通知消息，iPhone上已經有了比較簡單的
和完美的推送通知解決方案，可是Android平台上實現起來卻相對比較麻煩，最近利用幾天的時間對Android的推送通知服務進行初步的研究。

在Android手機平台上，Google提供了C2DM（Cloudto Device Messaging）服務，起初我就是准備採用這個服務來實現自己手機上的推送功能。

Android Cloud to Device Messaging
(C2DM)是一個用來幫助開發者從伺服器向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，允許伺服器可以通知移動應用

程序直接與伺服器進行通信，以便於從伺服器獲取應用程序更新和用戶數據。C2DM服務負責處理諸如消息排隊等事務並向運行於目標設備上的應用程序分發這些
消息。

但是經過一番研究發現，這個服務存在很大的問題：

1）C2DM內置於Android的2.2系統上，無法兼容老的1.6到2.1系統;

2）C2DM需要依賴於Google官方提供的C2DM伺服器，由於國內的網路環境，這個服務經常不可用，如果想要很好的使用，我們的App Server必須也在國外，這個恐怕不是每個開發者都能夠實現的;

有了上述兩個使用上的制約，導致我最終放棄了這個方案，不過我想利用另外一篇文章來詳細的介紹C2DM的框架以及客戶端和App Server的相應設置方法，可以作為學習與參考之用。

即然C2DM無法滿足我們的要求，那麼我們就需要自己來實現Android手機客戶端與App Server之間的通信協議，保證在App Server想向指定的Android設備發送消息時，Android設備能夠及時的收到。下面我來介紹幾種常見的方案：

1）輪詢：應用程序應當階段性的與伺服器進行連接並查詢是否有新的消息到達，你必須自己實現與伺服器之間的通信，例如消息排隊等。而且你還要考慮輪詢的頻率，如果太慢可能導致某些消息的延遲，如果太快，則會大量消耗網路帶寬和電池。

2）SMS：在Android平台上，你可以通過攔截SMS消息並且解析消息內容來了解伺服器的意圖。這是一個不錯的想法，我就見過採用這個方案的

應用程序。這個方案的好處是，可以實現完全的實時操作。但是問題是這個方案的成本相對比較高，你很難找到免費的短消息發送網關，關於這個方案的實現，可以
參考如下鏈接：https://labs.ericsson.com/apis/mobile-java-push/。

3）持久連接：這個方案可以解決由輪詢帶來的性能問題，但是還是會消耗手機的電池。Apple的推送服務之所以工作的很好，是因為每一台手機僅僅保

持一個與伺服器之間的連接，事實上C2DM也是這么工作的。不過這個方案也存在不足，就是我們很難在手機上實現一個可靠的服務。Android操作系統允
許在低內存情況下殺死系統服務，所以你的通知服務很可能被操作系統Kill掉了。

前兩個方案存在明顯的不足，第三個方案也有不足，不過我們可以通過良好的設計來彌補，以便於讓該方案可以有效的工作。畢竟，我們要知道GMail，GTalk以及GoogleVoice都可以實現實時更新的。

Ø 採用MQTT協議實現Android推送

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

我們可以從這里下載該項目的實例代碼，並且可以找到一個採用PHP書寫的伺服器端實現。

架構如下所示：

wmqtt.jar 是IBM提供的MQTT協議的實現。你可以從如下站點下載它。你可以將該jar包加入你自己的Android應用程序中。

Really Small Message Broker (RSMB) ，他是一個簡單的MQTT代理，同樣由IBM提供。預設打開1883埠，應用程序當中，它負責接收來自伺服器的消息並將其轉發給指定的移動設備。

SAM是一個針對MQTT寫的PHP庫。你可以從這個下載它.

send_mqtt.php是一個通過POST接收消息並且通過SAM將消息發送給RSMB的PHP腳本。

實例代碼：

可以從GitHub上下載實例應用。運行該應用以後，通過手機瀏覽器訪問http://toku.com/demo/android-push/,在第一個輸入框輸入設備ID，在第二個輸入框輸入想要發送的消息內容，按下「Send Push Message」按鈕，你就應該可以看到手機上收到了通知了。你也可以從這個GitHub地址上下載android-push源代碼，它包含了send_mqtt.php腳本。

Ø 採用XMPP協議實現Android推送

這是我在項目中採用的方案。事實上Google官方的C2DM伺服器底層也是採用XMPP協議進行的封裝。

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

androidpn是一個基於XMPP協議的java開源Android push notification實現。它包含了完整的客戶端和伺服器端。經過源代碼研究我發現，該伺服器端基本是在另外一個開源工程openfire基礎上修改實現的，不過比較郁悶的是androidpn的文檔是由韓語寫的，所以整個研究過程基本都是讀源碼。它的實現示意圖如下：

androidpn客戶端需要用到一個基於java的開源XMPP協議包asmack，這個包同樣也是基於openfire下的另外一個開源項目smack，
不過我們不需要自己編譯，可以直接把androidpn客戶端裡面的asmack.jar拿來使用。客戶端利用asmack中提供的
XMPPConnection類與伺服器建立持久連接，並通過該連接進行用戶注冊和登錄認證，同樣也是通過這條連接，接收伺服器發送的通知。

androidpn伺服器端也是java語言實現的，基於openfire開源工程，不過它的Web部分採用的是spring框架，這一點與
openfire是不同的。Androidpn伺服器包含兩個部分，一個是偵聽在5222埠上的XMPP服務，負責與客戶端的
XMPPConnection類進行通信，作用是用戶注冊和身份認證，並發送推送通知消息。另外一部分是Web伺服器，採用一個輕量級的HTTP伺服器，
負責接收用戶的Web請求。伺服器架構如下：

最上層包含四個組成部分，分別是SessionManager，Auth
Manager，PresenceManager以及Notification
Manager。SessionManager負責管理客戶端與伺服器之間的會話，Auth Manager負責客戶端用戶認證管理，Presence
Manager負責管理客戶端用戶的登錄狀態，NotificationManager負責實現伺服器向客戶端推送消息功能。

伺服器端界面如下，分別對應了上述的幾個功能模塊：

發送以後，我們可以在手機端看到接收的消息：

這個解決方案的最大優勢就是簡單，我們不需要象C2DM那樣依賴操作系統版本，也不會擔心某一天Google伺服器不可用。利用XMPP協議我們還可以進一步的對協議進行擴展，實現更為完善的功能。
採用這個方案，我們目前只能發送文字消息，不過對於推送來說一般足夠了，因為我們不能指望通過推送得到所有的數據，一般情況下，利用推送只是告訴手機端伺服器發生了某些改變，當客戶端收到通知以後，應該主動到伺服器獲取最新的數據，這樣才是推送服務的完整實現。

㈡ 蘋果app推送消息每條都是2遍，煩死了。

如發現有大的流量抄消耗，請在該軟體的「設置＞通知」中修改每個軟體的推送狀態，或者直接在iPhone的「設置＞通知」中關閉「通知」，即關閉所有軟體推送功能（如是iPhone4用戶還需要雙擊「HOME」鍵，屏幕下面出現運行程序條，長按該程序圖標將圖標關閉，或者卸載相關推送軟體。

㈢ 選擇第三方APP消息推送都參考哪些指標呢

相關指標有很多，像是否收費、推送內容形式等等。但是要站在用戶的角度為他們多想版想的話，首先還權是要考慮到達率、推送效率以及省電省流量的問題。我們應用做的是視頻類的，用的個推，以上幾項指標都測試下來都挺不錯的，覺得值得一試。

㈣ Mob push 消息推送是什麼有什麼特點

Push是app內的一種推廣方式，是一種將信息實時發送到用戶的手機中，push 的推送功能回可以讓產品給用戶快速及答時發起交互，向用戶推送提醒、動態等消息，push也可以向特定的用戶群體、區域發送，可以提高用戶的活躍度和留存率，同時也可以發布營銷活動等消息。

㈤ 什麼是推送消息啊

推送消息是通過一定的技術標准或協議，在網路上通過定期傳送用戶需要的信息來減少信息過載的一項新技術。

推送技術通過自動傳送信息給用戶，來減少用於網路上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其定期推給用戶，幫助用戶高效率地發掘有價值的信息。

(5)參考消息推送擴展閱讀：

在移動互聯網時代以前的手機，如果有事情發生需要通知用戶，則會有一個窗口彈出，將告訴用戶正在發生什麼事情。可能是未接電話的提示，日歷的提醒，或是一封新的彩信。推送功能最早是被用於Email中，用來提示我們新的信息。

由於時代的發展和移動互聯網的熱潮，推送功能更加地普及，已經不再僅僅用在推送郵件了，更多地用在我們的APP中了。

當我們開發需要和伺服器交互的應用程序時，基本上都需要獲取伺服器端的數據，比如《地震應急通》就需要及時獲取伺服器上最新的地震信息。要獲取伺服器上不定時更新的信息，一般來說有兩種方法：

第一種是客戶端使用Pull（拉）的方式，就是隔一段時間就去伺服器上獲取一下信息，看是否有更新的信息出現。

第二種就是 伺服器使用Push（推送）的方式，當伺服器端有新信息了，則把最新的信息Push到客戶端上。這樣，客戶端就能自動的接收到消息。 

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

㈥ 哪些安卓手機的消息推送做的好

都不錯的。
相對來說，華為，小米等做得好些。

㈦ 怎樣做點擊推送消息，跳轉到指定頁面

JPush SDK 收到推送，通過廣播的方式，轉發給開發者App，這樣開發者就可以靈活地進行處理。
這個動作不是必須的。用戶有需要才定義 Receiver 類來處理 SDK過來的廣播。
如果不做這個動作，即不寫自定義 Receiver，也不在 AndroidManifest.xml 里配置這個 Receiver，則默認的行為是：
接收到推送的自定義消息，則沒有被處理
可以正常收到通知，用戶點擊打開應用主界面
接受廣播
如果全部類型的廣播都接收，則需要在 AndroidManifest.xml 里添加如下的配置信息：

<receiver
android:name="Your Receiver"
android:enabled="true">
<intent-filter>
<action android:name="cn.jpush.android.intent.REGISTRATION" />
<action android:name="cn.jpush.android.intent.MESSAGE_RECEIVED" />
<action android:name="cn.jpush.android.intent.NOTIFICATION_RECEIVED" />
<action android:name="cn.jpush.android.intent.NOTIFICATION_OPENED" />

<category android:name="You package Name" />
</intent-filter>
</receiver>

每個 Receiver action 詳細解釋如下。
Action - cn.jpush.android.intent.REGISTRATION
SDK 向 JPush Server 注冊所得到的注冊 ID 。
一般來說，可不處理此廣播信息。
要深入地集成極光推送，開發者想要自己保存App用戶與JPush 用戶關系時，則接受此廣播，取得 Registration ID 並保存與App uid 的關繫到開發者自己的應用伺服器上。
使用極光推送提供的別名與標簽功能，是更加簡單輕便的綁定App用戶與JPush用戶的方式，請參考文檔：別名與標簽使用教程。
Intent 參數
JPushInterface.EXTRA_REGISTRATION_ID
SDK 向 JPush Server 注冊所得到的注冊 全局唯一的 ID ，可以通過此 ID 向對應的客戶端發送消息和通知。

Bundle bundle = intent.getExtras();
String title = bundle.getString(JPushInterface.EXTRA_REGISTRATION_ID);

Action - cn.jpush.android.intent.MESSAGE_RECEIVED
收到了自定義消息 Push 。
SDK 對自定義消息，只是傳遞，不會有任何界面上的展示。
如果開發者想推送自定義消息 Push，則需要在 AndroidManifest.xml 里配置此 Receiver action，並且在自己寫的 BroadcastReceiver 里接收處理。
Intent 參數
JPushInterface.EXTRA_TITLE
保存伺服器推送下來的消息的標題。
對應 API 消息內容的 title 欄位。
對應 Portal 推送消息界面上的「標題」欄位（可選）.

Bundle bundle = intent.getExtras();
String title = bundle.getString(JPushInterface.EXTRA_TITLE);

JPushInterface.EXTRA_MESSAGE
保存伺服器推送下來的消息內容。
對應 API 消息內容的 message 欄位。
對應 Portal 推送消息界面上的"消息內容」欄位。

Bundle bundle = intent.getExtras();
String message = bundle.getString(JPushInterface.EXTRA_MESSAGE);

JPushInterface.EXTRA_EXTRA
保存伺服器推送下來的附加欄位。這是個 JSON 字元串。
對應 API 消息內容的 extras 欄位。
對應 Portal 推送消息界面上的「自定義內容」。

Bundle bundle = intent.getExtras();
String extras = bundle.getString(JPushInterface.EXTRA_EXTRA);

JPushInterface.EXTRA_CONTENT_TYPE
保存伺服器推送下來的內容類型。
對應 API 消息內容的 content_type 欄位。

Bundle bundle = intent.getExtras();
String type = bundle.getString(JPushInterface.EXTRA_CONTENT_TYPE);

JPushInterface.EXTRA_RICHPUSH_FILE_PATH
SDK 1.4.0 以上版本支持。
富媒體通消息推送下載後的文件路徑和文件名。

Bundle bundle = intent.getExtras();
String file = bundle.getString(JPushInterface.EXTRA_RICHPUSH_FILE_PATH);

JPushInterface.EXTRA_MSG_ID

SDK 1.6.1 以上版本支持。
唯一標識消息的 ID, 可用於上報統計等。

Bundle bundle = intent.getExtras();
String file = bundle.getString(JPushInterface.EXTRA_MSG_ID);

Action - cn.jpush.android.intent.NOTIFICATION_RECEIVED
收到了通知 Push。

如果通知的內容為空，則在通知欄上不會展示通知。但是，這個廣播 Intent 還是會有。開發者可以取到通知內容外的其他信息。

Intent 參數
JPushInterface.EXTRA_NOTIFICATION_TITLE

保存伺服器推送下來的通知的標題。
對應 API 通知內容的 n_title 欄位。
對應 Portal 推送通知界面上的「通知標題」欄位。

Bundle bundle = intent.getExtras();
String title = bundle.getString(JPushInterface.EXTRA_NOTIFICATION_TITLE);

JPushInterface.EXTRA_ALERT

保存伺服器推送下來的通知內容。
對應 API 通知內容的 n_content 欄位。

對應 Portal 推送通知界面上的「通知內容」欄位。

Bundle bundle = intent.getExtras();
String content = bundle.getString(JPushInterface.EXTRA_ALERT);

JPushInterface.EXTRA_EXTRA
SDK 1.2.9 以上版本支持。
保存伺服器推送下來的附加欄位。這是個 JSON 字元串。
對應 API 通知內容的 n_extras 欄位。
對應 Portal 推送通知界面上的「自定義內容」欄位。

Bundle bundle = intent.getExtras();
String extras = bundle.getString(JPushInterface.EXTRA_EXTRA);

JPushInterface.EXTRA_NOTIFICATION_ID
SDK 1.3.5 以上版本支持。
通知欄的Notification ID，可以用於清除Notification

Bundle bundle = intent.getExtras();
int notificationId = bundle.getInt(JPushInterface.EXTRA_NOTIFICATION_ID);

JPushInterface.EXTRA_CONTENT_TYPE
保存伺服器推送下來的內容類型。
對應 API 消息內容的 content_type 欄位。
Portal 上暫時未提供輸入欄位。

Bundle bundle = intent.getExtras();
String type = bundle.getString(JPushInterface.EXTRA_CONTENT_TYPE);

JPushInterface.EXTRA_RICHPUSH_HTML_PATH
SDK 1.4.0 以上版本支持。
富媒體通知推送下載的HTML的文件路徑,用於展現WebView。

Bundle bundle = intent.getExtras();
String fileHtml = bundle.getString(JPushInterface.EXTRA_RICHPUSH_HTML_PATH);

JPushInterface.EXTRA_RICHPUSH_HTML_RES

SDK 1.4.0 以上版本支持。
富媒體通知推送下載的圖片資源的文件名,多個文件名用 「，」 分開。 與 「JPushInterface.EXTRA_RICHPUSH_HTML_PATH」 位於同一個路徑。

Bundle bundle = intent.getExtras();
String fileStr = bundle.getString(JPushInterface.EXTRA_RICHPUSH_HTML_RES);
String[] fileNames = fileStr.spilt(",");

JPushInterface.EXTRA_MSG_ID

SDK 1.6.1 以上版本支持。
唯一標識通知消息的 ID, 可用於上報統計等。

Bundle bundle = intent.getExtras();
String file = bundle.getString(JPushInterface.EXTRA_MSG_ID);

Action - cn.jpush.android.intent.NOTIFICATION_OPENED
用戶點擊了通知。
一般情況下，用戶不需要配置此 receiver action。
如果開發者在 AndroidManifest.xml 里未配置此 receiver action，那麼，SDK 會默認打開應用程序的主 Activity，相當於用戶點擊桌面圖標的效果。
如果開發者在 AndroidManifest.xml 里配置了此 receiver action，那麼，當用戶點擊通知時，SDK 不會做動作。開發者應該在自己寫的 BroadcastReceiver 類里處理，比如打開某 Activity 。
Intent 參數
JPushInterface.EXTRA_NOTIFICATION_TITLE
保存伺服器推送下來的通知的標題。
對應 API 通知內容的 n_title 欄位。
對應 Portal 推送通知界面上的「通知標題」欄位。

Bundle bundle = intent.getExtras();
String title = bundle.getString(JPushInterface.EXTRA_NOTIFICATION_TITLE);

JPushInterface.EXTRA_ALERT
保存伺服器推送下來的通知內容。
對應 API 通知內容的n_content欄位。
對應 Portal 推送通知界面上的「通知內容」欄位。

Bundle bundle = intent.getExtras();
String content = bundle.getString(JPushInterface.EXTRA_ALERT);

JPushInterface.EXTRA_EXTRA
SDK 1.2.9 以上版本支持。
保存伺服器推送下來的附加欄位。這是個 JSON 字元串。
對應 API 消息內容的 n_extras 欄位。
對應 Portal 推送通知界面上的「自定義內容」欄位。

Bundle bundle = intent.getExtras();
String type = bundle.getString(JPushInterface.EXTRA_EXTRA);

JPushInterface.EXTRA_NOTIFICATION_ID

SDK 1.3.5 以上版本支持。
通知欄的Notification ID，可以用於清除Notification

Bundle bundle = intent.getExtras();
int notificationId = bundle.getInt(JPushInterface.EXTRA_NOTIFICATION_ID

JPushInterface.EXTRA_MSG_ID

SDK 1.6.1 以上版本支持。
唯一標識調整消息的 ID, 可用於上報統計等。

Bundle bundle = intent.getExtras();
String file = bundle.getString(JPushInterface.EXTRA_MSG_ID);

代碼示例

public void onReceive(Context context, Intent intent) {
Bundle bundle = intent.getExtras();
Log.d(TAG, "onReceive - " + intent.getAction());

if (JPushInterface.ACTION_REGISTRATION_ID.equals(intent.getAction())) {

} else if (JPushInterface.ACTION_MESSAGE_RECEIVED.equals(intent.getAction())) {
System.out.println("收到了自定義消息。消息內容是：" + bundle.getString(JPushInterface.EXTRA_MESSAGE));
// 自定義消息不會展示在通知欄，完全要開發者寫代碼去處理
} else if (JPushInterface.ACTION_NOTIFICATION_RECEIVED.equals(intent.getAction())) {
System.out.println("收到了通知");
// 在這里可以做些統計，或者做些其他工作
} else if (JPushInterface.ACTION_NOTIFICATION_OPENED.equals(intent.getAction())) {
System.out.println("用戶點擊打開了通知");
// 在這里可以自己寫代碼去定義用戶點擊後的行為
Intent i = new Intent(context, TestActivity.class); //自定義打開的界面
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(i);

} else {
Log.d(TAG, "Unhandled intent - " + intent.getAction());
}
}

㈧ 如何自己搭建一個xmpp，實現推送消息

Android推送方案分析（MQTT/XMPP/GCM）
蝸牛TT 發布於 4個月前，共有 11 條評論
本文主旨在於，對目前Android平台上最主流的幾種消息推送方案進行分析和對比，比較客觀地反映出這些推送方案的優缺點，幫助大家選擇最合適的實施方案。
方案1、使用GCM服務（Google Cloud Messaging）
簡介：Google推出的雲消息服務，即第二代的G2DM。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用戶綁定Google帳號，受限於Google。

方案2、使用XMPP協議（Openfire + Spark + Smack）
簡介：基於XML協議的通訊協議，前身是Jabber，目前已由IETF國際標准化組織完成了標准化工作。
優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。
缺點：協議較復雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。

方案3、使用MQTT協議（更多信息見：http://mqtt.org/）
簡介：輕量級的、基於代理的「發布/訂閱」模式的消息傳輸協議。
優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域（參考：http://mqtt.org/software），且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較復雜、服務端組件rsmb不開源，部署硬體成本較高。

方案4、使用HTTP輪循方式
簡介：定時向HTTP服務端介面（Web Service API）獲取最新消息。
優點：實現簡單、可控性強，部署硬體成本低。
缺點：實時性差。

對各個方案的優缺點的研究和對比，推薦使用MQTT協議的方案進行實現，主要原因是：MQTT最快速，也最省流量（固定頭長度僅為2位元組），且極易擴展，適合二次開發。接下來，我們就來分析使用MQTT方案進行Android消息的原理和方法，並架設自己的推送服務。

如果還不明白的 話，要看分析的話，給你個網址：http://m.oschina.net/blog/82059
自己看看。

㈨ 為什麼參考消息的內容不更新

參考消息的媒體發布渠道主要有
網站、APP、微信和微博
是每日一推送
具體時間不清楚
望採納

㈩ 什麼是反向推送消息

所謂信息推送，就是"web廣播"，是通過一定的技術標准或協議，在互聯網上通過定期傳送用版戶需要的信息來減少信權息過載的一項新技術。推送技術通過自動傳送信息給用戶，來減少用於網路上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其定期推給用戶，幫助用戶高效率地發掘有價值的信息。