1.名詞解釋

API Key - 應(yīng)用標(biāo)識(shí)，終端上的綁定和服務(wù)端推送消息時(shí)都要用到。

Secret Key - 應(yīng)用私鑰，服務(wù)端推送消息時(shí)用到。

app id - 應(yīng)用ID，就是百度開(kāi)發(fā)者中心的應(yīng)用基本信息中的應(yīng)用ID?？蛻?hù)端綁定調(diào)用返回值中可獲得。

channel id - 推送通道ID，通常指一個(gè)終端，如一臺(tái)android系統(tǒng)手機(jī)?？蛻?hù)端綁定調(diào)用返回值中可獲得。

user id - 應(yīng)用的用戶(hù)ID，一個(gè)應(yīng)用在多個(gè)端可以都屬于同一用戶(hù)。user id和channel id配合可以唯一指定一個(gè)應(yīng)用的特定終端。如果應(yīng)用不是基于百度賬戶(hù)的賬戶(hù)體系，單獨(dú)用user就通常指定了一個(gè)應(yīng)用的特定終端。客戶(hù)端綁定調(diào)用返回值中可獲得。

2.單播消息推送

描述

開(kāi)發(fā)者向應(yīng)用的特定終端或特定用戶(hù)推送消息。 特定終端對(duì)于應(yīng)用來(lái)說(shuō)，就是安裝了應(yīng)用的一臺(tái)具體的設(shè)備。 而一個(gè)用戶(hù)可能有多個(gè)端，在某些應(yīng)用場(chǎng)景下，我們希望消息是針對(duì)用戶(hù)的——應(yīng)用的同一個(gè)用戶(hù)在他的所有終端上都能收到消息，這時(shí)候我們就需要向特定用戶(hù)推送消息。

解決思路

(1)向應(yīng)用的特定終端推送消息

一個(gè)channel id指定一個(gè)終端，因此在這種需求下，開(kāi)發(fā)者需要通過(guò)服務(wù)端API，向一個(gè)特定channel id推送消息。在推送之前，客戶(hù)端應(yīng)用通過(guò)綁定接口的返回值獲取到channel id，并通過(guò)網(wǎng)絡(luò)等手段發(fā)送給開(kāi)發(fā)者，開(kāi)發(fā)者需自行維護(hù)channel id。

例如，Android客戶(hù)端，在調(diào)用了startWork之后，自定義消息 receiver將會(huì)收到返回值，其中包含了channel id、user id等信息。

(2)向應(yīng)用的特定用戶(hù)推送消息

云推送用user id來(lái)表示用戶(hù)，因此在這種需求下，開(kāi)發(fā)者需要通過(guò)服務(wù)端API，向一個(gè)特定user id推送消息。和channel id獲取方式類(lèi)似，客戶(hù)端應(yīng)用通過(guò)綁定接口的返回值獲取到user id。開(kāi)發(fā)者需要自行維護(hù)user id。

應(yīng)用場(chǎng)景舉例

在線(xiàn)問(wèn)答應(yīng)用。用戶(hù)A用手機(jī)發(fā)表一個(gè)問(wèn)題，問(wèn)題的解答并不是實(shí)時(shí)的。假設(shè)在第二天用戶(hù)B發(fā)表了第一個(gè)解答，這時(shí)需要將答案單獨(dú)推送給A。

解決方案

用戶(hù)A發(fā)表問(wèn)題時(shí)，記錄問(wèn)題id及其對(duì)應(yīng)的A的user id（或channel id）。用戶(hù)B發(fā)表解答時(shí)，通過(guò)服務(wù)端API向問(wèn)題id對(duì)應(yīng)的user id（或channel id）推送解答。

3.用戶(hù)分組的消息推送

描述

開(kāi)發(fā)者向應(yīng)用的符合特定分類(lèi)條件的若干用戶(hù)的集合推送消息。廣播是分組推送的特例，它向應(yīng)用的所有用戶(hù)（同時(shí)也是所有端）推送消息。

解決思路

云推送通過(guò)Tag（標(biāo)簽）這種技術(shù)方式來(lái)實(shí)現(xiàn)用戶(hù)分組的功能。例如，對(duì)于分類(lèi)信息的應(yīng)用，一個(gè)用戶(hù)觀(guān)看了體育欄目，就給該用戶(hù)打一個(gè)Tag——sport。6月的某一天NBA總決賽熱火奪冠了，則向sport這個(gè)Tag推送一條及時(shí)的奪冠新聞。

Tag的設(shè)置有兩種方法：

(1)客戶(hù)端設(shè)置

這是最常見(jiàn)的設(shè)置方式，因?yàn)楹陀脩?hù)直接交互的客戶(hù)端最真實(shí)的收集了用戶(hù)的喜好、習(xí)慣等信息。這些信息往往是用戶(hù)分組的依據(jù)。在客戶(hù)端程序中，一旦用戶(hù)觸發(fā)了開(kāi)發(fā)者預(yù)先設(shè)定的分組條件（如：觀(guān)看了體育欄目，設(shè)置了年齡，團(tuán)購(gòu)了電影票等），則調(diào)用客戶(hù)端API進(jìn)行Tag設(shè)置（對(duì)應(yīng)的Tag：sport，80s，movie），如Android端的setTags接口。

(2)服務(wù)端設(shè)置

如果開(kāi)發(fā)者自己維護(hù)了用戶(hù)的分組信息，或者存在已發(fā)布的還不具備某分組設(shè)置功能的終端版本，也可以通過(guò)服務(wù)端API給特定用戶(hù)設(shè)置Tag，如PHP接口setTag。

廣播功能和Tag無(wú)關(guān)，不需要開(kāi)發(fā)者進(jìn)行分組的任何操作就已經(jīng)具備。

推送Tag消息的方法：

(3)通過(guò)管理控制臺(tái)推送

若要推送廣播消息，選中上圖中的所有人即可。

(4)通過(guò)服務(wù)端API推送

如PHP接口

public function pushMessage ( 
$push_type, 
$messages, 
$message_keys, 
$optional = NULL ) 

push_type為2，且正確設(shè)置tag_name 參數(shù)。詳情參考PHP-SDK使用手冊(cè)。

應(yīng)用場(chǎng)景舉例

閱讀應(yīng)用。對(duì)不同閱讀喜好的人群推送不同類(lèi)別的新圖書(shū)廣告。

解決方案

應(yīng)用提供喜好設(shè)置頁(yè)面，用戶(hù)勾選不同的類(lèi)別，觸發(fā)對(duì)應(yīng)Tag的設(shè)置?；蛘哂脩?hù)閱讀了某個(gè)類(lèi)別的圖書(shū)，觸發(fā)對(duì)應(yīng)Tag的設(shè)置。在服務(wù)端，給特定類(lèi)別圖書(shū)的Tag推送新書(shū)廣告。

4.使用自己的賬戶(hù)系統(tǒng)或百度賬戶(hù)

描述

開(kāi)發(fā)者可以使用自己的賬戶(hù)體系開(kāi)發(fā)應(yīng)用，或者應(yīng)用就是無(wú)賬戶(hù)的。開(kāi)發(fā)者也可選擇使用百度賬戶(hù)作為應(yīng)用賬戶(hù)系統(tǒng)的接入。

解決思路

(1)使用自己的賬戶(hù)系統(tǒng)或者無(wú)賬戶(hù)系統(tǒng)

這兩種情況，云推送都是無(wú)法理解賬戶(hù)信息的，所以對(duì)于云推送來(lái)說(shuō)都屬于無(wú)賬戶(hù)體系。
云推送通過(guò)終端標(biāo)識(shí)（channel id）和應(yīng)用標(biāo)識(shí)（APIKey）來(lái)唯一確定一個(gè)應(yīng)用的一個(gè)特定端。應(yīng)用的每個(gè)端都是不同的用戶(hù)，擁有不同的user id。 客戶(hù)端的綁定方式，用Android API舉例：

PushManager.startWork(Context, LOGIN_TYPE_API_KEY, apiKey)

(2)使用百度賬戶(hù)系統(tǒng)

云推送和百度賬戶(hù)系統(tǒng)是連通的，應(yīng)用的所有用戶(hù)將使用百度的user id作為唯一標(biāo)識(shí)。不同的端使用同一個(gè)用戶(hù)百度賬戶(hù)登錄，獲得的user id是一樣的。這種方式可以實(shí)現(xiàn)對(duì)用戶(hù)的多個(gè)端做消息推送。
百度賬戶(hù)的客戶(hù)端綁定使用用戶(hù)AccessToken作為驗(yàn)證憑證，用戶(hù)AccessToken的獲得需要百度賬戶(hù)登錄界面的輔助，具體使用可以參看客戶(hù)端SDK demo或者百度賬號(hào)連接官方文檔。
同樣的，客戶(hù)端的綁定方式，用Android API舉例：

PushManager.startWork(Context, LOGIN_TYPE_ACCESS_TOKEN, UserAccessToken)

(2) 百度賬號(hào)連接官方文檔

5.單服務(wù)單通道的端上實(shí)現(xiàn)

云推送的Android SDK，是通過(guò)后臺(tái)service和socket長(zhǎng)連接機(jī)制來(lái)實(shí)現(xiàn)的。從消息時(shí)效性、耗電量、網(wǎng)絡(luò)流量等因素考慮，這是目前最好的實(shí)現(xiàn)方式。

在同一臺(tái)設(shè)備安裝了多個(gè)使用推送的應(yīng)用的情況下，如果每個(gè)應(yīng)用都執(zhí)行獨(dú)立的后臺(tái)service，且各自建立獨(dú)立的長(zhǎng)連接，這無(wú)疑是系統(tǒng)資源的巨大浪費(fèi)。內(nèi)存使用、耗電量、網(wǎng)絡(luò)流量等關(guān)鍵因素都將以接近與應(yīng)用數(shù)正比的倍數(shù)增長(zhǎng)。

在這個(gè)背景下，云推送實(shí)現(xiàn)了單服務(wù)單通道的機(jī)制。同一臺(tái)設(shè)備上，云推送服務(wù)的資源消耗不受集成該服務(wù)的應(yīng)用數(shù)量影響。任何時(shí)刻，只會(huì)運(yùn)行一個(gè)后臺(tái)service和維持一個(gè)socket長(zhǎng)連接。

應(yīng)用的初始化、tag等接口調(diào)用，將通過(guò)intent方式發(fā)送到后臺(tái)運(yùn)行的service處理。service接收到推送消息時(shí)，將根據(jù)消息中指定的發(fā)送對(duì)象，通過(guò)intent，以指定目標(biāo)應(yīng)用包名的方式，發(fā)送私有消息給應(yīng)用。應(yīng)用無(wú)法接收到不屬于自己的消息，也無(wú)法通過(guò)冒充截獲。

示意圖：