DDPush 任意门消息推送 开源免费实时信息推送服务器
在好幾年前，就已經(jīng)注意到DDPush這款推送中間件，不過看近來發(fā)展也還是停留在V1.0的基礎(chǔ)上，不免惋惜！恰好最近正在深入研究Java Socket通信編程，也順帶再看看這款應(yīng)用。官網(wǎng)地址：http://www.ddpush.net/
目錄
DDPush 任意門 消息推送
DDPush是什么
DDPush可以做什么
移動(dòng)互聯(lián)網(wǎng)消息推送
IM實(shí)時(shí)消息系統(tǒng)核心組件
物聯(lián)網(wǎng)設(shè)備控制與交互
DDPush消息推送有什么優(yōu)勢(shì)
開源、免費(fèi)
容量高，速度快，要求低
終端設(shè)備流量少，省電
DDPush消息推送基于什么技術(shù)
DDPush消息推送 概述
IM(Instant Messaging)即時(shí)通訊系統(tǒng)
DDPush消息推送的思路
DDPush消息推送的策略
通用終端的支持
使用DDPush消息推送的方式
事情其實(shí)很簡(jiǎn)單
DDPush消息推送 快速開始
第一步：下載DDPush消息推送服務(wù)器與Android安卓demo app安裝文件
第二步：運(yùn)行DDPush消息推送服務(wù)器
第三步：手機(jī)安裝與運(yùn)行Android安卓demo app
DDPush消息推送 一分鐘集成
第一步，繼承并實(shí)現(xiàn)客戶端抽象基類
繼承UDP或者TCP客戶端抽象基類
實(shí)現(xiàn)三個(gè)抽象函數(shù)
public boolean hasNetworkConnection()
public void trySystemSleep()
public void onPushMessage(Message message)
第二步，運(yùn)行客戶端
第三步，應(yīng)用服務(wù)端推送信息
Android客戶端
安卓demo apk耗電分析
48小時(shí)在線測(cè)試結(jié)果（UDP，TCP，微信）
DDPush Android UDP Demo 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
DDPush Android TCP Demo 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
微信 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
360省電王評(píng)價(jià)
耗電小結(jié)
DDPush消息推送 網(wǎng)絡(luò)流量分析
終端上載流量
終端下載流量
服務(wù)器流量
小結(jié)
UDP對(duì)TCP
互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)網(wǎng)絡(luò)環(huán)境
智能終端電池續(xù)航能力，系統(tǒng)休眠
IPv4資源、端口資源
端口映射老化時(shí)間
服務(wù)端承載能力
高級(jí)應(yīng)用網(wǎng)絡(luò)通訊要求
結(jié)論
DDPush 任意門推送 1 下載
系統(tǒng)要求
最新版本1.0.03 (2015-01-02發(fā)布)
二進(jìn)制發(fā)布
源碼發(fā)布
歷史版本1.0.02 (2014-08-29發(fā)布, 2014-11-21更新android示例工程)
二進(jìn)制發(fā)布
源碼發(fā)布
歷史版本1.0.01 (2014-08-01)
二進(jìn)制發(fā)布
源碼發(fā)布
?
DDPush 任意門 消息推送
DDPush是什么
DDPush (Dimension Door Push)，任意門消息推送，是一款開源免費(fèi)的單機(jī)千萬級(jí)實(shí)時(shí)消息推送服務(wù)器，使用Java語言開發(fā)，具有簡(jiǎn)單、穩(wěn)定、高性能、高容量等特點(diǎn)，適用于互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、Android、智能設(shè)備、硬件設(shè)備等各種環(huán)境。
DDPush可以做什么
移動(dòng)互聯(lián)網(wǎng)消息推送
DDPush可實(shí)時(shí)推送信息到各種Android、Windows等手機(jī)和平板（即“透?jìng)鳌?#xff09;，并支持雙向通信。DDPush支持自定義信息，信息的格式和內(nèi)容可由開發(fā)者自行定義
IM實(shí)時(shí)消息系統(tǒng)核心組件
通過集成DDPush消息推送，可以開發(fā)各種IM實(shí)時(shí)消息系統(tǒng)，例如：聊天系統(tǒng)、社交App等。
物聯(lián)網(wǎng)設(shè)備控制與交互
DDPush消息推送可作為一個(gè)實(shí)時(shí)控制中心，控制物聯(lián)網(wǎng)中的各種硬件設(shè)備（硬件需支持網(wǎng)絡(luò)通信），與之雙向通信。
DDPush消息推送有什么優(yōu)勢(shì)
開源、免費(fèi)
DDPush采用Apache License Version 2.0開源協(xié)議，可放心使用，只要您保留其許可證信息。
容量高，速度快，要求低
DDPush在線部分主要采用UDP協(xié)議（同時(shí)支持TCP協(xié)議），支撐1000萬終端在線的服務(wù)器，最少只需要4G內(nèi)存（不考慮變長(zhǎng)自定義信息的情況下），單個(gè)主流雙核CPU使用率低于75%。即：一部普通PC臺(tái)式機(jī)的配置。
DDPush推送部分采取TCP協(xié)議和Java NIO非阻塞網(wǎng)絡(luò)技術(shù)，普通PC可支持至少數(shù)千臺(tái)應(yīng)用服務(wù)器同時(shí)長(zhǎng)連接推送信息到終端，每秒推送信息的速度在1萬條以上
終端設(shè)備流量少，省電
采用DDPush，智能手機(jī)等終端設(shè)備在線一個(gè)月（空載的情況下），只需幾百KB的上載流量，下載流量甚至可調(diào)節(jié)到為零。
DDPush提供的Android手機(jī)App示例demo，連續(xù)在線48小時(shí)耗電少于0.5 mAh（使用2G網(wǎng)絡(luò)GPRS連接，經(jīng)360省電王測(cè)試??>>>詳情）
DDPush消息推送基于什么技術(shù)
DDPush基于自有的二進(jìn)制網(wǎng)絡(luò)傳輸協(xié)議（基于TCP和UDP），因此客戶端可以支持各種類型的終端設(shè)備，包括各種智能手機(jī)、平板、智能設(shè)備、物聯(lián)網(wǎng)硬件，和各種終端操作系統(tǒng)（包括: Android, Windows, Linux等）。
DDPush使用Java語言開發(fā)，因此服務(wù)端可運(yùn)行在各種操作系統(tǒng)和服務(wù)器上。
DDPush消息推送 概述
IM(Instant Messaging)即時(shí)通訊系統(tǒng)
IM(Instant Messaging)即時(shí)通訊系統(tǒng)，從1996年ICQ的出現(xiàn)，到國(guó)際巨頭割據(jù)的今天，已經(jīng)深刻地影響了互聯(lián)網(wǎng)，甚至人類社會(huì)的變化。從移動(dòng)互聯(lián)網(wǎng)時(shí)代開始，即時(shí)通訊系統(tǒng)更是加劇演變進(jìn)化，除了iOS和Android提供全世界范圍的Push Notification Service，還形成了各種開放的云推送平臺(tái)與服務(wù)，成為巨頭廝殺圈地的戰(zhàn)場(chǎng)。在可預(yù)見的物聯(lián)網(wǎng)前景下，相信IM即時(shí)通訊系統(tǒng)將會(huì)進(jìn)一步進(jìn)化，成為物聯(lián)智能時(shí)代的IT基礎(chǔ)設(shè)施之一。
然而，到目前為止，即時(shí)通訊（包括其衍生的云推送平臺(tái)與服務(wù)）一直被賦予高難度、高投入的標(biāo)簽，似乎成了強(qiáng)者的專屬，普通開發(fā)者和中小型IT公司的業(yè)務(wù)大都依賴現(xiàn)有的第三方產(chǎn)品或服務(wù)，先不說可能面臨高額的收費(fèi)，從信息安全角度來說，把自己的客戶與業(yè)務(wù)建立在第三方服務(wù)的基礎(chǔ)上，也讓很多人心存顧慮。雖然業(yè)界也有各種較流行的開源實(shí)現(xiàn)，但其普及程度還比較低。另外，由于目前的開源實(shí)現(xiàn)，普遍基于較高級(jí)的應(yīng)用層面（例如：XMPP），所以其實(shí)現(xiàn)較為復(fù)雜，普通技術(shù)人員不容易掌控和二次開發(fā)，并且越高級(jí)的應(yīng)用，其通用性往往越低。
DDPush消息推送的思路
DDPush的出發(fā)點(diǎn)，是繞過已有的各種門檻和障礙，尋求另外一種簡(jiǎn)單有效的方法，來嘗試折衷地實(shí)現(xiàn)移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)時(shí)代IM系統(tǒng)需求。DDPush的目的是幫助中小型應(yīng)用和個(gè)人開發(fā)者，較容易地跨過IM系統(tǒng)的基本門檻，而不是挑戰(zhàn)和取代已有的業(yè)界標(biāo)準(zhǔn)和產(chǎn)品。DDPush，任意門推送服務(wù)器，只是另外一道門，也許能打開另外一個(gè)世界，但絕不是包含整個(gè)世界。
DDPush的思路，有點(diǎn)類似MQTT，重新定義了一套較簡(jiǎn)單和低級(jí)的網(wǎng)絡(luò)通訊協(xié)議，來達(dá)到更小的流量、更高的效率、以及更好的通用性。而DDPush和MQTT的區(qū)別在于，DDPush更為簡(jiǎn)單，放棄了QoS，只實(shí)現(xiàn)極為簡(jiǎn)單的實(shí)時(shí)通訊需求，剩下的更多是交由應(yīng)用層去控制。另外，DDPush實(shí)現(xiàn)并主推UDP方式，大為降低網(wǎng)絡(luò)通信成本和服務(wù)器承載成本，提高了容量和效率。
這個(gè)特點(diǎn)是DDPush與其他方案一個(gè)區(qū)別所在。DDPush認(rèn)為可靠性、完整性，更多是應(yīng)該由應(yīng)用層去控制的，而不是網(wǎng)絡(luò)通信層。理由是在移動(dòng)互聯(lián)網(wǎng)、無線物聯(lián)網(wǎng)的環(huán)境下，網(wǎng)絡(luò)本身就是非常不穩(wěn)定的因素（至少在很長(zhǎng)一段時(shí)間內(nèi)都會(huì)是這樣），因此不能寄望其能完美地工作，需要應(yīng)用層的保證。例如：當(dāng)收到一封郵件的時(shí)候，應(yīng)該是嘗試發(fā)出一個(gè)通知告訴郵箱所有者有新郵件達(dá)到，即使通知失敗了，也不影響直接登錄郵箱查看新郵件，同時(shí)也應(yīng)保留再次通知的可能。設(shè)想一下，如果僅僅因?yàn)閷?shí)時(shí)通知失敗了，就連新郵件都丟失的話，豈不是本末倒置？
DDPush消息推送的策略
因此，DDPush采取的策略是：不努力保證單次數(shù)據(jù)包的實(shí)時(shí)和必然到達(dá)，改為可能的多次通知直至終端主動(dòng)確認(rèn)，來提高“通知”的最終成功率。換句話說，DDPush犧牲部分的實(shí)時(shí)性，來?yè)Q取更高的成功率，信息可能即時(shí)達(dá)到，也可能十幾分鐘后到達(dá)，甚至幾天后到達(dá)（如果終端幾天后上線的話），但一般總會(huì)到達(dá)。（當(dāng)然，需要實(shí)時(shí)的時(shí)候還是可以實(shí)現(xiàn)的，因?yàn)镈DPush的行為是可配置的，也支持TCP模式）
正因?yàn)槿绱?#xff0c;DDPush主推UDP協(xié)議，DDPush的通信協(xié)議格式就類似UDP協(xié)議，基于包的形式而不是流的形式，不依賴包的順序。不過，DDPush同時(shí)也用TCP實(shí)現(xiàn)了相同的協(xié)議，有需要的情況下只要打開TCP模式即可。這里需要聲明的是：UDP模式的服務(wù)器容量，是TCP的幾十倍甚至上百倍，請(qǐng)使用者自行權(quán)衡。
注：在設(shè)計(jì)DDPush的早期，作者也曾考慮引入部分QoS的功能，例如重發(fā)次數(shù)、重發(fā)策略等。但最后作者決定放棄大部分QoS功能，把這些問題留給應(yīng)用層去控制，將更精確更實(shí)用，也能大大簡(jiǎn)化DDPush的復(fù)雜度和提高容量與效率。畢竟，業(yè)務(wù)邏輯由應(yīng)用層去控制，在線終端的數(shù)量由DDPush去保證，各司其職，應(yīng)該是一種更恰當(dāng)?shù)姆绞健＞秃孟襦]件是否已讀，應(yīng)該由郵件系統(tǒng)控制，而不是新郵件提醒功能去完成。
不過，DDPush并不是完全沒有QoS功能，只是采取了更簡(jiǎn)單的，和MQTT三種QoS級(jí)別都不一樣的QoS功能：等待終端確認(rèn)；外加應(yīng)用層、終端實(shí)現(xiàn)的個(gè)性化配合手段，達(dá)到更大的自由度。
通用終端的支持
DDPush采取UDP協(xié)議的另外一個(gè)好處，是對(duì)終端設(shè)備的通用支持。對(duì)于常見操作系統(tǒng)（Windows、Android等）來說，網(wǎng)絡(luò)操作的支持完全不是問題，只是程序通用性的問題。而對(duì)于很多嵌入式Linux系統(tǒng)、普通硬件設(shè)備來說，要實(shí)現(xiàn)完整的網(wǎng)絡(luò)通信協(xié)議，特別是TCP這種高級(jí)應(yīng)用層協(xié)議，是非常困難甚至有時(shí)候是不太可能的任務(wù)（與芯片、板卡的能力和成本有關(guān)），所以是本質(zhì)的通用性問題。而對(duì)于UDP，普通硬件設(shè)備和嵌入式系統(tǒng)則能較好地支持，因?yàn)槠鋸?fù)雜度、難度都低很多，各方面要求也相應(yīng)降低。DDPush采用二進(jìn)制網(wǎng)絡(luò)通信協(xié)議，而不是文本協(xié)議，這也與很多硬件設(shè)備有更多的契合點(diǎn)。這些特點(diǎn)和MQTT很類似，不過目前MQTT協(xié)議是基于TCP協(xié)議而不是UDP。
使用DDPush消息推送的方式
對(duì)于XMPP等其他方式，很多開發(fā)者習(xí)慣直接使用其來傳遞信息內(nèi)容。而DDPush提倡傳遞“控制信息”，類似FTP的工作模式。即：通過DDPush來傳遞命令和控制信息，真正的內(nèi)容信息建議終端使用常見的HTTP GET或者新建TCP連接的方式，連接到應(yīng)用服務(wù)器（而不是DDPush服務(wù)器）獲取。這里還會(huì)涉及安全驗(yàn)證、內(nèi)容有效性等方面的需求，而DDPush不致力于解決類似的問題（MQTT則包括安全驗(yàn)證等規(guī)則）。DDPush專注在“通知的下發(fā)和確認(rèn)”方面。
事情其實(shí)很簡(jiǎn)單
DDPush不管是協(xié)議本身，還是代碼實(shí)現(xiàn)，其實(shí)都是很簡(jiǎn)單的。因此，開發(fā)者很容易進(jìn)行改造和二次開發(fā)，或者按照自己的需要重新改寫。整個(gè)DDPush服務(wù)器的Java代碼量很少，目前只有200K，編譯后的二進(jìn)制文件不到100k，對(duì)于大部分開發(fā)者來說要讀懂，相信并不困難。這也是DDPush希望達(dá)到的效果，讓即時(shí)通訊、推送成為家常菜，而不是滿漢全席。
DDPush消息推送 快速開始
歡迎來到DDPush快速開始，本頁(yè)面將引導(dǎo)您快速體驗(yàn)DDPush的基本功能，請(qǐng)按照以下三個(gè)步驟操作：
第一步：下載DDPush消息推送服務(wù)器與Android安卓demo app安裝文件
第二步：運(yùn)行DDPush消息推送服務(wù)器
第三步：安裝與運(yùn)行Android安卓demo app
第一步：下載DDPush消息推送服務(wù)器與Android安卓demo app安裝文件
請(qǐng)點(diǎn)擊以下鏈接下載文件：
DDPush服務(wù)器
安卓客戶端app示例（UDP）
安卓客戶端app示例（TCP）
第二步：運(yùn)行DDPush消息推送服務(wù)器
解壓DDPush消息推送服務(wù)器壓縮文件到您電腦的某個(gè)目錄（路徑不要包含中文或空格），您將看到2個(gè)目錄與4個(gè)文件。
目錄：lib, logs
文件：start.bat, start.sh, console.bat, console.sh
如果您在使用Windows操作系統(tǒng)，請(qǐng)執(zhí)行start.bat文件（注：勿雙擊bat文件，請(qǐng)于CMD窗口中運(yùn)行）；如果您使用的是Linux系統(tǒng)，請(qǐng)執(zhí)行start.sh文件。這里使用Windows系統(tǒng)演示，執(zhí)行start.bat文件。如果您看到類似以下的信息，說明DDPush服務(wù)器已經(jīng)運(yùn)行：
您也可以檢查logs目錄下是否有ddpush.out日志文件輸出來判斷DDPush是否在運(yùn)行。此外，您還可檢查DDPush的默認(rèn)端口是否正在監(jiān)聽。
如果您要停止DDPush消息推送服務(wù)器，請(qǐng)新打開一個(gè)命令行窗口，執(zhí)行命令："console.bat stop"，DDPush服務(wù)器將會(huì)停止
Linux系統(tǒng)下的操作與Windows類似，差別在于Linux系統(tǒng)下執(zhí)行的是start.sh和console.sh腳本。
注意：如果您通過ftp單獨(dú)上傳sh腳本文件到Linux服務(wù)器，注意不要破壞文件格式，如出現(xiàn)無法運(yùn)行sh腳本的情況，請(qǐng)嘗試使用dos2unix命令轉(zhuǎn)換文本格式，并確保sh文件權(quán)限為可執(zhí)行
第三步：手機(jī)安裝與運(yùn)行Android安卓demo app
請(qǐng)使用Android手機(jī)分別安裝第一步下載的另外兩個(gè)apk文件。您也可以使用兩臺(tái)手機(jī)分別安裝，以達(dá)到更現(xiàn)實(shí)的體驗(yàn)效果
安裝完畢后，打開兩個(gè)app，配置服務(wù)器IP為您在第二步中運(yùn)行DDPush消息推送服務(wù)器的機(jī)器IP，見下圖
?
按照上圖的示例，兩個(gè)app分別設(shè)置不同的用戶名，并把目標(biāo)用戶名設(shè)置為對(duì)方，以測(cè)試互相推送信息。這里是user01和user02，各端口號(hào)采用默認(rèn)值。
注意正確設(shè)置服務(wù)器IP為第二步中DDPush消息推送服務(wù)器運(yùn)行機(jī)器的IP，并且手機(jī)能正常訪問網(wǎng)絡(luò)與該IP。
分別點(diǎn)擊"開始測(cè)試"按鈕后，即可通過下面的按鈕來互相發(fā)送推送信息，見下圖收到的實(shí)時(shí)推送信息示例。（若延時(shí)數(shù)分鐘后才收到推送信息亦屬正常情況，請(qǐng)檢查網(wǎng)絡(luò)是否暢通，服務(wù)器IP地址是否可達(dá)）
當(dāng)然，您也可以只安裝其中一個(gè)app demo，然后自己給自己發(fā)送推送信息，只要把用戶名、目標(biāo)用戶名設(shè)置為同一個(gè)字符串即可。
>>> demo app耗電嗎？
DDPush消息推送 一分鐘集成
集成使用DDPush消息推送服務(wù)器，只需要簡(jiǎn)單繼承DDPush提供的Java客戶端基類，并實(shí)現(xiàn)三個(gè)簡(jiǎn)單的函數(shù)，即可使用DDPush服務(wù)，不需要了解客戶端與服務(wù)端網(wǎng)絡(luò)協(xié)議交互的細(xì)節(jié)。
DDPush提供的客戶端基類，已經(jīng)滿足大部分的應(yīng)用場(chǎng)景。此外，DDPush提供的Android App客戶端示例，還實(shí)現(xiàn)了Android開發(fā)中的后臺(tái)長(zhǎng)時(shí)間運(yùn)行的service服務(wù)，您可以直接使用。
若DDPush提供的現(xiàn)成基類和示例無法滿足您的應(yīng)用場(chǎng)景，你可以改寫或者重寫DDPush客戶端。這并不會(huì)很困難，但需要您了解DDPush自身的網(wǎng)絡(luò)協(xié)議。當(dāng)然，這個(gè)也不會(huì)是很困難的事情。
馬上開始！
第一步，繼承并實(shí)現(xiàn)客戶端抽象基類
繼承UDP或者TCP客戶端抽象基類
UDP：public class MyUdpClient extends org.ddpush.im.v1.client.appuser.UDPClientBase
TCP：public class MyTcpClient extends org.ddpush.im.v1.client.appuser.TCPClientBase
實(shí)現(xiàn)三個(gè)抽象函數(shù)
public boolean hasNetworkConnection(){}
public void onPushMessage(org.ddpush.im.v1.client.appuser.Message msg){}
public void trySystemSleep(){}
public boolean hasNetworkConnection()
該函數(shù)主要用于智能終端，判斷當(dāng)前是否有可用的網(wǎng)絡(luò)連接，以達(dá)到省電的目的（若無網(wǎng)絡(luò)連接則不嘗試網(wǎng)絡(luò)操作）。不同的終端檢測(cè)網(wǎng)絡(luò)情況的方式會(huì)不一樣，所以DDPush客戶端示例要求您的實(shí)現(xiàn)自行判斷網(wǎng)絡(luò)連接是否可用。如果是PC版軟件不需考慮省電，可簡(jiǎn)單返回true，哪怕實(shí)際上沒有可用的網(wǎng)絡(luò)連接。
public void trySystemSleep()
該函數(shù)同樣主要用于智能終端，在客戶端不需要發(fā)送心跳包，并且服務(wù)端無推送信息的時(shí)候，嘗試系統(tǒng)休眠，達(dá)到省電的目的。PC版軟件可以直接將該函數(shù)留空，不做任何處理。Android則可能要考慮釋放WakeLock以進(jìn)入系統(tǒng)休眠狀態(tài)。
public void onPushMessage(Message message)
該函數(shù)是客戶端處理推送信息的業(yè)務(wù)入口函數(shù)。當(dāng)客戶端收到服務(wù)端的推送命令，將自動(dòng)發(fā)送確認(rèn)包，然后調(diào)用該函數(shù)。所以該函數(shù)內(nèi)或其調(diào)用的其他函數(shù)，應(yīng)該確保信息的正確處理，因?yàn)檎Ｇ闆r下該推送信息已經(jīng)確認(rèn)，極可能不會(huì)再次收到通知。
DDPush現(xiàn)成的客戶端基類，會(huì)在該函數(shù)返回后，再調(diào)用trySystemSleep()函數(shù)。因此該函數(shù)內(nèi)不用考慮保有WakeLock等防止系統(tǒng)休眠的操作。
第二步，運(yùn)行客戶端
UDP客戶端：
MyUdpClient myUdpClient = new MyUdpClient(uuid,1,"192.168.1.100",9966);
myUdpClient.setHeartbeatInterval(50);//50秒一次心跳，可由您動(dòng)態(tài)調(diào)節(jié)
myUdpClient.start();
TCP客戶端：
MyTcpClient myTcpClient = new MyTcpClient(uuid, 1, "192.168.1.100", 9966, 5);
myTcpClient.setHeartbeatInterval(50);//50秒一次心跳
myTcpClient.start();
若網(wǎng)絡(luò)發(fā)生變化，客戶端會(huì)自行處理。
程序退出關(guān)閉客戶端：myUdpClient.stop()或者myTcpClient.stop()。
第三步，應(yīng)用服務(wù)端推送信息
Pusher pusher = new Pusher(serverIp,port, timeoutMills);
boolean result = pusher.push0x20Message(uuid,message);
注：這個(gè)步驟一般應(yīng)該是應(yīng)用服務(wù)器向DDPush消息推送服務(wù)器發(fā)起，但在DDPush Android demo工程里面，為了方便直接在客戶端調(diào)用，只是為了演示如何編程。
Android客戶端
在Android App開發(fā)中，會(huì)涉及到其他特有的因素，例如service的持續(xù)運(yùn)行、WakeLock的控制等，并非簡(jiǎn)單繼承基類實(shí)現(xiàn)以上三個(gè)函數(shù)就能正常工作。請(qǐng)參考DDPush提供的Android客戶端示例App
?
安卓demo apk耗電分析
目前全世界所有智能手機(jī)的電池續(xù)航能力都是瓶頸，因此app耗電的大小是app開發(fā)者非常關(guān)注的一個(gè)點(diǎn)，特別是長(zhǎng)期聯(lián)網(wǎng)運(yùn)行的app。
DDPush提供的Android安卓App客戶端demo，一方面展示DDPush的使用，另外一個(gè)方面也提供了現(xiàn)成的，集成了在線服務(wù)的Android開發(fā)示例。該示例通過了一系列的長(zhǎng)期運(yùn)行測(cè)試，確保在省電省流量方面達(dá)到較好的水平。
48小時(shí)在線測(cè)試結(jié)果（UDP，TCP，微信）
以下內(nèi)容展示了Android demo app在GPRS連接（2G網(wǎng)絡(luò)）下連續(xù)空載運(yùn)行48小時(shí)后的耗電、喚醒時(shí)間統(tǒng)計(jì)，并與微信作比較。（使用WakeLock Detector和360省電王測(cè)試）
?
以上圖片顯示，GPRS連接（2G網(wǎng)絡(luò)）下連續(xù)運(yùn)行48小時(shí)，DDPush的UDP demo、TCP demo和微信的喚醒次數(shù)、總喚醒時(shí)間基本持平，在20至25分鐘左右。
DDPush Android UDP Demo 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
如圖所示，48小時(shí)內(nèi)UDP Demo喚醒605次，喚醒時(shí)間21分16秒，耗電0.4 mAh
DDPush Android TCP Demo 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
如圖所示，48小時(shí)內(nèi)TCP Demo喚醒606次，喚醒時(shí)間20分18秒，耗電0.3 mAh
微信 耗電、喚醒次數(shù)、喚醒時(shí)間詳情
如圖所示，48小時(shí)內(nèi)微信喚醒721次，喚醒時(shí)間25分41秒，耗電0.8 mAh
360省電王評(píng)價(jià)
如圖所示，360省電王對(duì)UDP和TCP演示app的耗電評(píng)價(jià)是"此軟件耗電極少，適合長(zhǎng)期后臺(tái)運(yùn)行，請(qǐng)放心使用"
注：360省電王版本為2.2.2.0001
耗電小結(jié)
綜上所述，在2G網(wǎng)絡(luò)GPRS連接情況下，TCP與UDP兩種方式的耗電基本沒差別，并且對(duì)手機(jī)電池的消耗較少，加上與微信的對(duì)比，證明方案可行。
DDPush消息推送 網(wǎng)絡(luò)流量分析
網(wǎng)絡(luò)流量，特別是無線電話網(wǎng)絡(luò)流量，有時(shí)候并不是它所應(yīng)該的那么便宜。即使不考慮價(jià)格因素，更快的速度、更高的通信效率這些目標(biāo)也決定了我們不能無節(jié)制地消耗流量，至少不環(huán)保。實(shí)際上，DDPush從設(shè)計(jì)的初期開始，就以盡可能少的網(wǎng)絡(luò)傳輸作為核心目標(biāo)。
終端上載流量
根據(jù)DDPush當(dāng)前的通信協(xié)議，終端上傳的一個(gè)UDP數(shù)據(jù)包，有效數(shù)據(jù)最少為21字節(jié)。加上UDP和IP包的首部長(zhǎng)度，不會(huì)超過70字節(jié)。移動(dòng)互聯(lián)網(wǎng)環(huán)境下，假設(shè)終端每5分鐘發(fā)送一次心跳包（這個(gè)是建議值，過于頻繁可能導(dǎo)致智能終端（手機(jī)）電池電量消耗過快），則一個(gè)月的上載數(shù)據(jù)量為70x12x24x30=604800字節(jié)，約合591K。這就是DDPush客戶端所消耗的上載流量（完全空載運(yùn)行情況下）。
實(shí)際情況可能有些不一樣，因?yàn)楫?dāng)手機(jī)處于非休眠狀態(tài)的時(shí)候（智能手機(jī)大部分時(shí)間都是休眠的），我們可能希望心跳的間隔小一些，以便更及時(shí)地收到實(shí)時(shí)信息，又不至于消耗過多的電（非休眠狀態(tài)下是非常耗電的，不在乎多耗一些了）。所以，DDPush客戶端的上傳流量會(huì)比上述的591K稍多一些。
終端下載流量
DDPush終端的下載流量遠(yuǎn)比上傳流量少（詳見協(xié)議內(nèi)容和使用文檔），而且在無信息通知的情況下，DDPush服務(wù)器可通過參數(shù)配置成不下發(fā)心跳，這時(shí)將不會(huì)有下載流量產(chǎn)生。當(dāng)然，這種情況下終端可能無法判斷自己是否在線。
服務(wù)器流量
對(duì)于服務(wù)器而言，主要的流量是入站流量，這與大部分互聯(lián)網(wǎng)服務(wù)恰恰相反（例如HTTP服務(wù)就是典型的入站流量小，出站流量大）。其實(shí)這也是IM系統(tǒng)的一個(gè)特點(diǎn)。根據(jù)DDPush的測(cè)試，獨(dú)享百兆帶寬出口(100m bits/second)的網(wǎng)絡(luò)，可支持一千萬以上終端同時(shí)在線（5分鐘一次心跳，平均每秒3.33萬個(gè)UDP心跳包，完全是DDPush的能力之內(nèi)，這時(shí)UDP包的成功率將近100%）
什么？獨(dú)享百兆出口帶寬太貴了？拜托，一千萬在線客戶，您已經(jīng)是土豪了，就別在乎那一點(diǎn)點(diǎn)帶寬費(fèi)用了......
小結(jié)
使用DDPush消息推送，終端設(shè)備基本可以忽略DDPush客戶端自身的流量；而服務(wù)端的流量，相對(duì)其收益來說，成本將是非常低的。
?
UDP對(duì)TCP
TCP還是UDP？長(zhǎng)連接如何實(shí)現(xiàn)？如何實(shí)現(xiàn)心跳機(jī)制？心跳的間隔如何確定？這些問題都是討論即時(shí)通訊、消息推送等類似話題時(shí)，幾乎一定被問到的問題。這里嘗試正本清源一下。
互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)網(wǎng)絡(luò)環(huán)境
在分析到底應(yīng)該使用UDP還是TCP之前，有必要先討論一下互聯(lián)網(wǎng)與移動(dòng)互聯(lián)網(wǎng)的網(wǎng)絡(luò)環(huán)境特點(diǎn)。
互聯(lián)網(wǎng)的網(wǎng)絡(luò)基礎(chǔ)建設(shè)，經(jīng)過十幾年長(zhǎng)期的發(fā)展，已經(jīng)較為穩(wěn)定和成熟，PC終端、操作系統(tǒng)的能力也達(dá)到了較高的水平。
而移動(dòng)互聯(lián)網(wǎng)，由于涉及到無線電話網(wǎng)絡(luò)基站、2G、3G和4G技術(shù)的不斷發(fā)展，其穩(wěn)定性、帶寬、資源分配等各方面雖日趨完善，但當(dāng)前終究還有不少問題的存在。另外，由于移動(dòng)互聯(lián)網(wǎng)其“移動(dòng)”的本質(zhì)，加上智能終端設(shè)備（智能手機(jī)、平板電腦）的發(fā)展較晚，目前還在不斷演變的情況，與互聯(lián)網(wǎng)相比，移動(dòng)互聯(lián)網(wǎng)還是低速、不穩(wěn)定、終端能力稍弱的情況。而且由于其“移動(dòng)”本質(zhì)，短時(shí)間內(nèi)很難達(dá)到互聯(lián)網(wǎng)的質(zhì)量。
所以，在互聯(lián)網(wǎng)的環(huán)境里面，網(wǎng)絡(luò)應(yīng)用程序由于網(wǎng)絡(luò)設(shè)施、操作系統(tǒng)的成熟，開發(fā)使用起來比較容易，資源也較為充足。而移動(dòng)互聯(lián)網(wǎng)還是要“斤斤計(jì)較”。
智能終端電池續(xù)航能力，系統(tǒng)休眠
智能終端設(shè)備的電池續(xù)航能力始終是技術(shù)瓶頸。在連續(xù)使用的情況下，絕大部分智能設(shè)備電池?zé)o法支持兩個(gè)小時(shí)以上。所以在沒有外部電源的情況，智能終端設(shè)備必須頻繁、長(zhǎng)時(shí)間休眠，這將極大地影響兩種網(wǎng)絡(luò)環(huán)境下的網(wǎng)絡(luò)應(yīng)用場(chǎng)景。
IPv4資源、端口資源
這個(gè)話題往往被很多人忽略，但它有著至關(guān)重要的影響。雖然大部分人都很清楚IP地址的緊缺導(dǎo)致的動(dòng)態(tài)IP分配的必然，卻忽略了由于IP地址不足引起的端口資源不足。
由于需要?jiǎng)討B(tài)分配IP地址（這里不僅僅指互聯(lián)網(wǎng)入口的IP，還包括局域網(wǎng)內(nèi)部的IP），路由器的工作原理都是經(jīng)過端口映射，把內(nèi)部網(wǎng)絡(luò)（包括PC、手機(jī)、平板、Wifi、2G、3G、4G）IP與端口映射成外部IP（通常是公網(wǎng)IP）和對(duì)應(yīng)的端口，并維持這個(gè)映射關(guān)系，才能正常地修改、轉(zhuǎn)發(fā)報(bào)文信息，保證內(nèi)部各個(gè)ip、端口與外部的各個(gè)ip、端口的通信。
然而，單個(gè)IP地址的端口資源是有限的，理論上限是65535個(gè)端口。對(duì)于普通寬帶路由器來說，這個(gè)已經(jīng)很充足了。但是！對(duì)于大型的網(wǎng)絡(luò)服務(wù)、網(wǎng)絡(luò)主干接入點(diǎn)等來說，如果IP資源不足，每個(gè)IP幾萬個(gè)端口的資源很快會(huì)耗盡，從而影響正常通訊。
端口映射老化時(shí)間
正因?yàn)槿绱?#xff0c;所有的路由器都會(huì)為每個(gè)端口映射關(guān)系設(shè)置老化時(shí)間，如果老化時(shí)間倒數(shù)到0，則端口映射關(guān)系失效，該端口被釋放給其他連接使用。如果端口全部耗盡，則無法再新建內(nèi)部與外部的網(wǎng)絡(luò)連接。
端口映射老化時(shí)間，比很多人想象中的要短很多。一般的家用寬帶路由器，老化時(shí)間一般是兩三分鐘；在有線寬帶運(yùn)營(yíng)商接入部分，老化時(shí)間可能少于兩分鐘。在無線電話網(wǎng)絡(luò)運(yùn)營(yíng)商接入部分（例如GPRS連接），老化時(shí)間甚至不超過一分鐘！
也就是說，任何一個(gè)網(wǎng)絡(luò)通訊（不管是TCP或UDP），如果幾分鐘之內(nèi)沒有網(wǎng)絡(luò)報(bào)文傳輸，其占用的IP地址端口將被路由器回收。這個(gè)時(shí)候該次通信必將終止，不管TCP還是UDP，神馬都是浮云。
更殘酷的事實(shí)是，互聯(lián)網(wǎng)可認(rèn)為是由無數(shù)個(gè)路由器連接而成的，一個(gè)網(wǎng)絡(luò)通信往往需要通過n個(gè)路由器，每個(gè)路由器都會(huì)為一次通信建立自己的端口映射。只要其中一個(gè)路由器回收其端口，則整個(gè)通訊中斷。
這也是很多人疑惑為什么TCP的KeepAlive參數(shù)無法保證長(zhǎng)連接的原因。TCP的KeepAlive默認(rèn)是兩個(gè)小時(shí)（而且該參數(shù)還是TCP的可選實(shí)現(xiàn)，不是必然實(shí)現(xiàn)），在路由器端口映射老化時(shí)間的影響下，必然無法發(fā)揮其作用。實(shí)際上，該參數(shù)在單一的局域網(wǎng)內(nèi)才可能被使用上，還要依賴具體的操作系統(tǒng)。
由于路由器端口映射的存在，加上智能終端頻繁、長(zhǎng)時(shí)間的休眠，TCP長(zhǎng)連接的實(shí)用性在移動(dòng)互聯(lián)網(wǎng)情況下極大地打了折扣。
也因?yàn)槿绱?#xff0c;IM系統(tǒng)必須實(shí)現(xiàn)所謂的心跳包機(jī)制，以保持端口映射關(guān)系的老化時(shí)間不會(huì)減少到0而被回收，從而避免連接中斷。
服務(wù)端承載能力
不管是UDP還是TCP，最終都是應(yīng)用服務(wù)端的設(shè)備去提供服務(wù)的。而TCP由于提供了安全可靠的流服務(wù)，其對(duì)計(jì)算機(jī)、網(wǎng)絡(luò)資源的消耗是遠(yuǎn)遠(yuǎn)大于UDP協(xié)議的。對(duì)于配置較好的主流服務(wù)器，配備大量的內(nèi)存（數(shù)十G至上百G內(nèi)存），與高速的磁盤、網(wǎng)卡，是能同時(shí)支持?jǐn)?shù)百萬個(gè)TCP連接的。不過這里需要較專業(yè)的服務(wù)器設(shè)置，需要調(diào)整不少系統(tǒng)參數(shù)，再加上服務(wù)程序的配合。另外，TCP連接的建立、維持與釋放，都是需要較昂貴的計(jì)算、網(wǎng)絡(luò)資源的。
終端在線服務(wù)，若是一個(gè)較為簡(jiǎn)單的服務(wù)，未必使用上TCP眾多的高級(jí)功能，但承受TCP的昂貴成本，未必值得。如果能用UDP來提供服務(wù)，單服務(wù)器的承載能力，是可以去到TCP服務(wù)的數(shù)十倍，甚至上百倍的增長(zhǎng)。這也是為什么DNS這種并發(fā)數(shù)巨大的服務(wù)器提供UDP接口的原因。
另外，上百萬TCP連接的網(wǎng)絡(luò)服務(wù)，其編程的難度、程序復(fù)雜度、調(diào)試難度、服務(wù)器運(yùn)維成本、網(wǎng)絡(luò)成本等都遠(yuǎn)遠(yuǎn)高于UDP。
而UDP編程，與上百萬個(gè)終端通訊的難度與成本則低很多。如果提供的網(wǎng)絡(luò)服務(wù)不是基于流的服務(wù)，也允許一定的失敗機(jī)率（例如P2P），則UDP往往是更適合的方式。
高級(jí)應(yīng)用網(wǎng)絡(luò)通訊要求
不過，即時(shí)通訊系統(tǒng)、推送系統(tǒng)一方面提供終端在線服務(wù)，另外一方面也需要考慮內(nèi)容信息的完整性和安全性。畢竟信息的丟失，或者通訊的被竊聽，都是難以接受的。而TCP不管在網(wǎng)絡(luò)層的可靠性控制，還是在應(yīng)用層的安全支持（例如HTTPS），都為應(yīng)用提供無法替代的強(qiáng)大功能和便利。
結(jié)論
綜合以上所述，其實(shí)答案也呼之欲出。
現(xiàn)在的即時(shí)通訊系統(tǒng)、推送系統(tǒng)，既面對(duì)移動(dòng)互聯(lián)網(wǎng)的不確定性，又面對(duì)智能終端頻繁的系統(tǒng)休眠、網(wǎng)絡(luò)切換，還要考慮服務(wù)端的承載成本，對(duì)于在線服務(wù)而言UDP是比TCP更適合的方式。但是由于數(shù)據(jù)完整性、安全性的需要，又不應(yīng)完全放棄TCP的可靠與安全。
所以，DDPush認(rèn)為，更恰當(dāng)?shù)姆绞綉?yīng)該是：兩種通信協(xié)議同時(shí)使用，各有側(cè)重。UDP用于保持大量終端的在線與控制，應(yīng)用與業(yè)務(wù)則通過TCP去實(shí)現(xiàn)。這個(gè)和FTP服務(wù)控制與數(shù)據(jù)分離，采取不同的連接，有異曲同工之處。
事實(shí)上，這個(gè)也是即時(shí)通訊巨頭QQ所采用的方式。早期的時(shí)候，QQ還是主要使用TCP協(xié)議，而后來就轉(zhuǎn)向了采用UDP的方式來保持在線，TCP的方式來上傳和下載數(shù)據(jù)。現(xiàn)在，UDP是QQ的默認(rèn)工作方式，表現(xiàn)良好。相信這個(gè)也被沿用到了微信上。
簡(jiǎn)單的考證：登錄PC版QQ，關(guān)閉多余的QQ窗口只留下主窗口，并將其最小化。幾分鐘過后，查看系統(tǒng)網(wǎng)絡(luò)連接，會(huì)發(fā)現(xiàn)QQ進(jìn)程已不保有任何TCP連接，但有UDP網(wǎng)絡(luò)活動(dòng)。這時(shí)在發(fā)送聊天信息，或者打開其他窗口和功能，將發(fā)現(xiàn)QQ進(jìn)程會(huì)啟用TCP連接。
最后，需要明確指出的是：DDPush只專注在保持和控制終端在線方面，而對(duì)于具體的應(yīng)用和業(yè)務(wù)，DDPush是基本不提供任何支持的。
DDPush 任意門推送 1 下載
歡迎來到DDPush任意門推送下載頁(yè)面。該頁(yè)面提供DDPush最新版本的下載鏈接，也包括舊的歷史版本。
注：Android示例工程app中使用到的ddpush相關(guān)類庫(kù)jar包，代碼實(shí)際是ddpush server中的client部分。
系統(tǒng)要求
Java 6.0或以上
最新版本1.0.03 (2015-01-02發(fā)布)
- 修復(fù)了app server端連續(xù)推送混合信息時(shí)，可能引起的掛起。
- 客戶端tcp超時(shí)默認(rèn)設(shè)置改為300秒。
- 控制臺(tái)取消僅允許本地網(wǎng)絡(luò)訪問的限制，可遠(yuǎn)程網(wǎng)絡(luò)連接控制臺(tái)。
- Android示例客戶端app無更新。
二進(jìn)制發(fā)布
DDPush Server v1.0.03
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發(fā)布
DDPush Server v1.0.03
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
歷史版本1.0.02 (2014-08-29發(fā)布, 2014-11-21更新android示例工程)
- UDP客戶端基類UDPClientBase.java增加getLastReceivedTime()方法，記錄服務(wù)器最后UDP包時(shí)間，可用于IM系統(tǒng)客戶端自我判斷是否在線或超時(shí)
- 修復(fù)了TCP模式下，自定義信息長(zhǎng)度較長(zhǎng)時(shí)引起數(shù)據(jù)紊亂的Bug。該Bug不影響UDP模式客戶端。
- 2014-11-21更新了android示例客戶端，包括TCP和UDP兩個(gè)工程，解決了部分安卓版本“很抱歉，‘xxxx’已停止運(yùn)行”的異常提示。
二進(jìn)制發(fā)布
DDPush Server v1.0.02
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發(fā)布
DDPush Server v1.0.02
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
歷史版本1.0.01 (2014-08-01)
DDPush誕生了
二進(jìn)制發(fā)布
DDPush Server v1.0.01
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發(fā)布
DDPush Server v1.0.01
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
?
總結(jié)
以上是生活随笔為你收集整理的DDPush 任意门消息推送 开源免费实时信息推送服务器的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java面向对象基础呕心沥血三千字
- 下一篇： 快乐起床歌.wav