關(guān)注主播上線提醒方法及系統(tǒng)與流程

本發(fā)明涉及互聯(lián)網(wǎng)消息推送領(lǐng)域，尤其涉及一種關(guān)注主播上線提醒方法及系統(tǒng)。

背景技術(shù)：

傳統(tǒng)方案中關(guān)于關(guān)注主播上線提醒方法中，通常是通過(guò)心跳或者第三方推送來(lái)推送消息。當(dāng)接收到服務(wù)器傳送過(guò)來(lái)的消息后客戶端進(jìn)行提示關(guān)注主播上線提醒。傳統(tǒng)方案有一個(gè)很大的缺陷。對(duì)于使用心跳保持客戶端與服務(wù)器的長(zhǎng)連接的方案中，當(dāng)客戶端在后臺(tái)運(yùn)行的時(shí)候，系統(tǒng)會(huì)發(fā)現(xiàn)客戶端在后臺(tái)一直發(fā)送心跳操作，所以系統(tǒng)很可能會(huì)將該應(yīng)用進(jìn)行殺掉。這樣就中斷了客戶端和服務(wù)器的連接，一旦客戶端和服務(wù)器的連接中斷，此時(shí)客戶端就無(wú)法接收到服務(wù)器推送過(guò)來(lái)的消息了。

對(duì)于使用第三方推送的方案，由于第三方推送的SDK做了很多的?；顑?yōu)化手段，確保第三方推送SDK能夠?；睿粫?huì)輕易被系統(tǒng)殺死。但是在部分手機(jī)上依舊會(huì)被系統(tǒng)殺死，導(dǎo)致推送消息無(wú)法進(jìn)行接收。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明要解決的技術(shù)問(wèn)題在于針對(duì)現(xiàn)有技術(shù)中推送消息容易被系統(tǒng)殺死的缺陷，提供一種提高消息推送成功率的關(guān)注主播上線提醒方法及系統(tǒng)。

本發(fā)明解決其技術(shù)問(wèn)題所采用的技術(shù)方案是：

提供一種關(guān)注主播上線提醒方法，包括以下步驟：

通過(guò)集成多個(gè)消息推送平臺(tái)向客戶端推送用戶所關(guān)注主播的上線消息，該上線消息為具有唯一標(biāo)識(shí)的上線消息；

判斷該上線消息是否已經(jīng)存在于指定存儲(chǔ)空間，若是，則舍棄該上線消息；若否，則將該上線消息發(fā)送到消息通知模塊，并將該上線消息存儲(chǔ)到所述指定存儲(chǔ)空間；

消息通知模塊通過(guò)通知欄發(fā)送該上線消息至客戶端。

本發(fā)明所述的方法中，該方法還包括步驟：

若客戶端的消息推送進(jìn)程被系統(tǒng)關(guān)閉，則重新向客戶端推送重新啟動(dòng)的模塊。

本發(fā)明所述的方法中，所述上線消息包括唯一標(biāo)識(shí)和消息內(nèi)容，消息內(nèi)容相同的上線消息的唯一標(biāo)識(shí)是相同的。

本發(fā)明所述的方法中，所述指定存儲(chǔ)空間為SharedPreferences存儲(chǔ)模塊，將上線消息保存到SharedPreferences的鍵值對(duì)中；其中鍵是上線消息的唯一標(biāo)識(shí)，值是消息的具體內(nèi)容。

本發(fā)明所述的方法中，具體通過(guò)安卓系統(tǒng)中的EventBus來(lái)發(fā)送上線消息。

本發(fā)明所述的方法中，若上線消息推送失敗，則通過(guò)服務(wù)器以向用戶發(fā)送短信消息的方式通知客戶。

本發(fā)明所述的方法中，在“重新向客戶端推送重新啟動(dòng)消息推送”之前還包括步驟：

在Android系統(tǒng)中注冊(cè)靜態(tài)廣播，接收網(wǎng)絡(luò)變化的回調(diào)消息；

根據(jù)接收的網(wǎng)絡(luò)變化的回調(diào)消息判定網(wǎng)絡(luò)狀態(tài)，若網(wǎng)絡(luò)連接正常，則重新向客戶端推送重新啟動(dòng)消息推送模塊；若網(wǎng)絡(luò)斷開(kāi)連接了，則不做任何處理。

本發(fā)明還提供一種關(guān)注主播上線提醒系統(tǒng)，包括：

平臺(tái)集成模塊，用于集成多個(gè)消息推送平臺(tái)向客戶端推送用戶所關(guān)注主播的上線消息，該上線消息為具有唯一標(biāo)識(shí)的上線消息；

消息過(guò)濾模塊，用于判斷該上線消息是否已經(jīng)存在于服務(wù)器的指定存儲(chǔ)空間，若是，則舍棄該上線消息；若否，則將該上線消息發(fā)送到消息通知模塊，并將該上線消息存儲(chǔ)到所述指定存儲(chǔ)空間；

消息通知模塊，用于通過(guò)通知欄發(fā)送該上線消息至客戶端。

本發(fā)明所述的系統(tǒng)中，該系統(tǒng)還包括：

推送恢復(fù)模塊，用于在客戶端的消息推送進(jìn)程被系統(tǒng)關(guān)閉時(shí)，重新向客戶端推送重新啟動(dòng)的模塊。

本發(fā)明產(chǎn)生的有益效果是：本發(fā)明通過(guò)集成多推送平臺(tái)向客戶端推送用戶所關(guān)注主播的上線消息，極大的提高了常規(guī)方案消息到達(dá)率。通過(guò)對(duì)消息的過(guò)濾，避免了消息的重復(fù)發(fā)送。

進(jìn)一步地，使用SharedPreferences的鍵值對(duì)來(lái)存儲(chǔ)數(shù)據(jù)，巧妙的使用消息唯一標(biāo)識(shí)和鍵值對(duì)中的鍵的唯一性，能夠提高識(shí)別消息是否處理過(guò)的效率。

進(jìn)一步地，通過(guò)EventBus來(lái)進(jìn)行消息轉(zhuǎn)發(fā)，屏蔽了常規(guī)廣播消息的很多弊端，優(yōu)勢(shì)明顯。極端情況下無(wú)法進(jìn)行推送時(shí)，使用短信對(duì)該方案進(jìn)行補(bǔ)充，確保消息一定能夠到達(dá)用戶。

附圖說(shuō)明

下面將結(jié)合附圖及實(shí)施例對(duì)本發(fā)明作進(jìn)一步說(shuō)明，附圖中：

圖1是本發(fā)明實(shí)施例注主播上線提醒方法的流程圖；

圖2是本發(fā)明另一實(shí)施例注主播上線提醒方法的流程圖；

圖3是本發(fā)明實(shí)施例廣播監(jiān)聽(tīng)的流程圖；

圖4是本發(fā)明實(shí)施例注主播上線提醒系統(tǒng)的結(jié)構(gòu)示意圖；

圖5是本發(fā)明另一實(shí)施例注主播上線提醒系統(tǒng)的結(jié)構(gòu)示意圖。

圖6是本發(fā)明第三實(shí)施例注主播上線提醒系統(tǒng)的結(jié)構(gòu)示意圖。

具體實(shí)施方式

為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下結(jié)合附圖及實(shí)施例，對(duì)本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說(shuō)明。應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

先對(duì)所涉及的專業(yè)名詞進(jìn)行解釋：

SharedPreferences：是Android平臺(tái)上一個(gè)輕量級(jí)的存儲(chǔ)類，用來(lái)保存應(yīng)用的一些常用配置。

SDK：軟件開(kāi)發(fā)工具包(SDK：Software Development Kit)一般是軟件工程師為特定的軟件包、軟件框架、硬件平臺(tái)、操作系統(tǒng)等建立應(yīng)用軟件時(shí)的開(kāi)發(fā)工具的集合。

EventBus：一種消息傳輸總線。

本發(fā)明提出了一套提高消息推送成功率的方案，通常較常規(guī)做法是集成一個(gè)推送平臺(tái)，但是無(wú)法保證該推送平臺(tái)不會(huì)被系統(tǒng)殺死。本發(fā)明中集成多個(gè)推送平臺(tái)，將多個(gè)推送平臺(tái)全部集成到應(yīng)用中，然后對(duì)推送消息進(jìn)行過(guò)濾處理，任何時(shí)候只要有一個(gè)推送平臺(tái)是存活狀態(tài)，就能夠接受到推送消息。這樣就能夠很大程度上的提升消息的到達(dá)率，從而能夠及時(shí)的將主播上線的消息推送給用戶。

在某些極端情況下如果發(fā)現(xiàn)所有的推送平臺(tái)都被系統(tǒng)殺死掉了，推送都是失敗的時(shí)候，會(huì)通過(guò)短信形式來(lái)告知用戶主播上線的消息。

通過(guò)本發(fā)明的技術(shù)實(shí)施，基本可以確保消息能夠100％被用戶接收到，這樣就能夠保證用戶不會(huì)錯(cuò)過(guò)所關(guān)注主播的上線消息。

如圖1所示，本發(fā)明的一個(gè)實(shí)施例關(guān)注主播上線提醒方法主要包括以下步驟：

S101、通過(guò)集成多個(gè)消息推送平臺(tái)向客戶端推送用戶所關(guān)注主播的上線消息，該上線消息為具有唯一標(biāo)識(shí)的上線消息；

S102、判斷該上線消息是否已經(jīng)存在于服務(wù)器的指定存儲(chǔ)空間，若是，則轉(zhuǎn)入執(zhí)行步驟S104；若否，則轉(zhuǎn)入執(zhí)行步驟S103；

S103、舍棄該上線消息；

S104、將該上線消息發(fā)送到消息通知模塊，并將該上線消息存儲(chǔ)到所述指定存儲(chǔ)空間；

S105、消息通知模塊通過(guò)通知欄發(fā)送該上線消息至客戶端。

其中，步驟S101中，對(duì)于多個(gè)消息推送平臺(tái)的集成，不同平臺(tái)集成方式大同小異，本發(fā)明實(shí)施例列舉其中一種舉例說(shuō)明(個(gè)推推送)，其他集成方式與此類似方式進(jìn)行集成。本發(fā)明通過(guò)集成多個(gè)推送平臺(tái)的SDK來(lái)提高消息推送的成功率，通過(guò)多個(gè)SDK同時(shí)對(duì)消息進(jìn)行推送，任何時(shí)候只要系統(tǒng)中任何一個(gè)推送SDK是存活狀態(tài)，就能夠接收到服務(wù)器推送過(guò)來(lái)的主播上線的消息。

本發(fā)明由于集成了多個(gè)推送SDK，每個(gè)SDK都有自己特有的一套保活方式，當(dāng)其中一個(gè)推送SDK失效后，只要有任何一個(gè)推送SDK是存活狀態(tài)，依舊能夠很好的接受到服務(wù)器傳遞過(guò)來(lái)的主播上線的消息信息。

由于集成方法是一個(gè)公開(kāi)通用的技術(shù)，本發(fā)明實(shí)施例中對(duì)此僅作簡(jiǎn)要概括：

1)在開(kāi)發(fā)者平臺(tái)創(chuàng)建應(yīng)用說(shuō)明

2)資源文件導(dǎo)入和配置文件引入

3)配置相關(guān)權(quán)限信息

4)導(dǎo)入通知欄圖標(biāo)

5)初始化SDK

6)資源精簡(jiǎn)配置

7)確認(rèn)Gradle配置

8)測(cè)試

整個(gè)集成過(guò)程大體分為上述的8個(gè)步驟，每個(gè)步驟都完成其中的相應(yīng)過(guò)程，具體每一步驟的細(xì)節(jié)針對(duì)每個(gè)平臺(tái)可能會(huì)有一定的差異性，這些集成過(guò)程都是公開(kāi)的方法。按照對(duì)應(yīng)的平臺(tái)的集成文檔對(duì)此進(jìn)行集成處理即可。

步驟S102-104是對(duì)信息的過(guò)濾。為了提高推送的成功率，本發(fā)明實(shí)施例中每次消息都是通過(guò)多個(gè)平臺(tái)進(jìn)行統(tǒng)一發(fā)送的。這樣就會(huì)造成一個(gè)問(wèn)題，那就是每次都可能接收到很多條重復(fù)的消息。因此需要對(duì)多條重復(fù)的消息進(jìn)行過(guò)濾處理。

過(guò)濾消息方法具體為：

為了能夠?qū)⑾⑦M(jìn)行過(guò)濾處理，本發(fā)明實(shí)施例中設(shè)計(jì)消息的時(shí)候給消息加入了一個(gè)tag標(biāo)簽，這個(gè)tag標(biāo)簽用于唯一表示一條消息。

消息的結(jié)構(gòu)體形式如下：

Tag：表示消息的標(biāo)簽，用于唯一表示一條消息，不同消息的tag是不同的，相同消息的tag是相同的。

Message：表示消息內(nèi)容

由于同時(shí)集成了多個(gè)推送模塊，并且消息是推送模塊進(jìn)行同時(shí)發(fā)送的。也就是說(shuō)我們可能在同一時(shí)間內(nèi)同時(shí)收到很多條相同的消息。

為了能夠用于區(qū)分消息是否被發(fā)送過(guò)，可將已經(jīng)處理過(guò)的消息會(huì)被保存到SharedPreferences存儲(chǔ)的鍵值對(duì)中。此處對(duì)于鍵值對(duì)的設(shè)計(jì)有一定的巧妙性，優(yōu)于消息的Tag是唯一的，在鍵值對(duì)的存儲(chǔ)中鍵也需要是唯一的。這樣就剛好可以將已經(jīng)處理過(guò)的消息通過(guò)SharedPreferences來(lái)進(jìn)行存儲(chǔ)，其中SharedPreferences存儲(chǔ)的鍵是消息的Tag，值是消息Message的內(nèi)容。

當(dāng)消息過(guò)來(lái)的時(shí)候，首先會(huì)去SharedPreferences中存儲(chǔ)的鍵值對(duì)中去查詢Tag所對(duì)應(yīng)的消息。

如果通過(guò)鍵值對(duì)獲取到了Tag所對(duì)應(yīng)的消息，說(shuō)明該消息已經(jīng)被處理過(guò)。此時(shí)可以舍棄掉該條消息，不對(duì)該條消息進(jìn)行處理。

如果通過(guò)鍵值對(duì)獲取Tag所對(duì)應(yīng)的消息為空，說(shuō)明該消息沒(méi)有被處理過(guò)。此時(shí)我們就可以將該消息發(fā)送到UI層進(jìn)行通知的彈出等處理。

本發(fā)明實(shí)施例使用SharedPreferences的鍵值對(duì)來(lái)存儲(chǔ)數(shù)據(jù)，巧妙的使用消息tag和鍵值對(duì)中的鍵的唯一性，能夠提高識(shí)別消息是否處理過(guò)的效率。

步驟S105是消息的發(fā)送，主要是將消息轉(zhuǎn)發(fā)到UI層(User Interface)來(lái)進(jìn)行處理，常規(guī)的消息轉(zhuǎn)發(fā)的方式通常是廣播形式來(lái)進(jìn)行轉(zhuǎn)發(fā)。本發(fā)明則優(yōu)選通過(guò)EventBus來(lái)進(jìn)行轉(zhuǎn)發(fā)。

傳統(tǒng)廣播轉(zhuǎn)發(fā)消息存在的問(wèn)題：

1、廣播消息的轉(zhuǎn)發(fā)，消息無(wú)法保證及時(shí)到達(dá)，會(huì)存在一定的延時(shí)性。由于系統(tǒng)所有的廣播都是通過(guò)一個(gè)消息處理模塊進(jìn)行處理的，如果系統(tǒng)中廣播消息過(guò)多的時(shí)候，就會(huì)出現(xiàn)消息阻塞，導(dǎo)致消息到達(dá)速度慢的問(wèn)題。

2、廣播下次的轉(zhuǎn)發(fā)使用起來(lái)復(fù)雜，廣播轉(zhuǎn)發(fā)一定存在三個(gè)部分，其一是發(fā)送消息，其二是注冊(cè)消息，其三是接受消息。這三個(gè)部分全部進(jìn)行整合后才能夠正確的接受到廣播發(fā)送過(guò)來(lái)的消息。使用起來(lái)步驟較多且復(fù)雜。

選擇EventBus的優(yōu)勢(shì)：

1、EventBus傳遞消息方便快捷，使用起來(lái)非常簡(jiǎn)潔。

2、EventBus僅僅處理自己發(fā)送模塊發(fā)送的消息，所有EventBus消息處理的數(shù)量上來(lái)說(shuō)是小于廣播消息的處理數(shù)量的，所以速度上會(huì)比廣播快。

3、Event不需要注冊(cè)，消息的接收和發(fā)送的綁定關(guān)系是通過(guò)消息體來(lái)進(jìn)行直接綁定的，也就是說(shuō)發(fā)送模塊只需要關(guān)注發(fā)送任務(wù)，接收模塊只需要關(guān)注接收和處理任務(wù)，使得整個(gè)代碼可維護(hù)性會(huì)更高。

使用EventBus來(lái)發(fā)送消息是通過(guò)sendEvent函數(shù)來(lái)進(jìn)行消息的發(fā)送的。接收函數(shù)是onEventHandler來(lái)接收處理發(fā)送過(guò)來(lái)的消息體。

當(dāng)接收到主播上線的消息后，就可以通過(guò)通知欄發(fā)送一條主播上線的消息給用戶，提示用戶主播上線的消息。

本發(fā)明實(shí)施例通過(guò)EventBus來(lái)進(jìn)行消息轉(zhuǎn)發(fā)，屏蔽了常規(guī)廣播消息的很多弊端，優(yōu)勢(shì)明顯。

如圖2所示，本發(fā)明實(shí)施例還包括推送恢復(fù)步驟，具體為：

S106、判斷客戶端的消息推送進(jìn)程是否被系統(tǒng)關(guān)閉；若是，則執(zhí)行步驟S107；

S107、重新向客戶端推送重新啟動(dòng)的模塊。即激發(fā)客戶端的消息推送進(jìn)程重新開(kāi)啟。

推送恢復(fù)的主要功能是當(dāng)系統(tǒng)將推送模塊殺死的時(shí)候，找機(jī)會(huì)將推送SDK重新啟動(dòng)。

由于推送一定會(huì)使用到網(wǎng)絡(luò)，所以上述推送恢復(fù)步驟主要功能是通過(guò)監(jiān)聽(tīng)系統(tǒng)網(wǎng)絡(luò)變化，如果方向系統(tǒng)網(wǎng)絡(luò)鏈接上的時(shí)候會(huì)主動(dòng)再次啟動(dòng)推送SDK，這樣就能夠大大的提升推送SDK長(zhǎng)期存活的概率。

如圖3所示，在步驟S107之前還包括步驟：

S301、在Android系統(tǒng)中注冊(cè)靜態(tài)廣播，接收網(wǎng)絡(luò)變化的回調(diào)消息；

S302、根據(jù)接收的網(wǎng)絡(luò)變化的回調(diào)消息判定網(wǎng)絡(luò)狀態(tài)，若網(wǎng)絡(luò)斷開(kāi)連接了，則不做任何處理；若網(wǎng)絡(luò)連接正常，則執(zhí)行步驟S303；

S303、重新向客戶端推送重新啟動(dòng)消息推送模塊；

接下來(lái)詳細(xì)描述上述的執(zhí)行流程：

步驟S301主要為廣播的監(jiān)聽(tīng)：

在Android系統(tǒng)中廣播分為靜態(tài)廣播和動(dòng)態(tài)廣播兩種類型，

靜態(tài)廣播：可以在應(yīng)用程序未啟動(dòng)的時(shí)候接受和處理廣播任務(wù)。

動(dòng)態(tài)廣播：必須得要應(yīng)用程序啟動(dòng)的時(shí)候才能夠接收，應(yīng)用程序退出了就不能接收了。

由于本發(fā)明目的期望最大程度上的激活推送SDK，所以本發(fā)明實(shí)施例選用靜態(tài)廣播來(lái)進(jìn)行注冊(cè)。

步驟S302主要判斷網(wǎng)絡(luò)連接狀態(tài)：

注冊(cè)網(wǎng)絡(luò)變化的廣播后，就能夠接收到網(wǎng)絡(luò)變化的回調(diào)消息。系統(tǒng)將所有網(wǎng)絡(luò)信息封裝到NetworkInfo類中，NetworkInfo類包含了當(dāng)前網(wǎng)絡(luò)的相關(guān)信息。接收到網(wǎng)絡(luò)變化的回調(diào)消息后，可以去判定網(wǎng)絡(luò)狀態(tài)。

判斷網(wǎng)絡(luò)狀態(tài)的方法是調(diào)用NetworkInfo中的isConnected方法來(lái)判定當(dāng)前網(wǎng)絡(luò)是否連接狀態(tài)。如果isConnected返回的是真，說(shuō)明網(wǎng)絡(luò)鏈接上了，此時(shí)我們需要重啟推送SDK框架。如果isConnected返回的是假，說(shuō)明此時(shí)網(wǎng)絡(luò)斷開(kāi)連接了，此時(shí)可不做任何處理。

步驟S303主要為重啟推送SDK：

如果檢測(cè)到網(wǎng)絡(luò)連接上我們需要重啟推送SDK，推送SDK模塊如果啟動(dòng)狀態(tài)下，我們?cè)俅握{(diào)用啟動(dòng)函數(shù)startPush不會(huì)再次重啟而是繼續(xù)運(yùn)行。如果推送SDK模塊處于停止?fàn)顟B(tài)下，調(diào)用startPush，此時(shí)會(huì)啟動(dòng)該推送SDK模塊。

通過(guò)推送恢復(fù)的設(shè)計(jì)，能夠?qū)⒈幌到y(tǒng)殺死的推送進(jìn)程進(jìn)行再次激活，這種激活方式可以確保推送SDK能夠再次被使用，大大提高了消息傳遞的成功率。

極端情況下無(wú)法發(fā)送消息時(shí)的處理方案：如果在某些極端情況下導(dǎo)致上述推送SDK全軍覆沒(méi)時(shí)，客戶端推送SDK停止運(yùn)行的時(shí)候，服務(wù)器端發(fā)送推送請(qǐng)求，由于沒(méi)有接收到SDK相關(guān)的反饋信息，服務(wù)器端會(huì)有推送超時(shí)信息接收。此時(shí)服務(wù)器就知道整個(gè)過(guò)程是失敗的。如果失敗了，此時(shí)會(huì)通過(guò)服務(wù)器來(lái)向用戶發(fā)送短信消息的方式進(jìn)行通知，確保主播上線消息能夠100％到達(dá)用戶。

此部分僅僅作為本發(fā)明的輔助處理方案，確保能夠在極端情況下導(dǎo)致無(wú)法接收到消息的時(shí)候，還可以通過(guò)短信通知的方式來(lái)告知用戶主播上線的消息。

為實(shí)現(xiàn)上述實(shí)施例的關(guān)注主播上線提醒方法，本發(fā)明還提供了關(guān)注主播上線提醒系統(tǒng)，如圖4所示，包括：

平臺(tái)集成模塊41，用于集成多個(gè)消息推送平臺(tái)向客戶端推送用戶所關(guān)注主播的上線消息，該上線消息為具有唯一標(biāo)識(shí)的上線消息；

消息過(guò)濾模塊42，用于判斷該上線消息是否已經(jīng)存在于服務(wù)器的指定存儲(chǔ)空間，若是，則舍棄該上線消息；若否，則將該上線消息發(fā)送到消息通知模塊，并將該上線消息存儲(chǔ)到所述指定存儲(chǔ)空間；

消息通知模塊43，用于通過(guò)通知欄發(fā)送該上線消息至客戶端。

如圖5所示，在上述實(shí)施例的基礎(chǔ)上，該系統(tǒng)還包括：

推送恢復(fù)模塊44，用于在客戶端的消息推送進(jìn)程被系統(tǒng)關(guān)閉時(shí)，重新向客戶端推送重新啟動(dòng)的模塊。

如圖6所示，在上述實(shí)施例的基礎(chǔ)上，該系統(tǒng)還包括短消息發(fā)送模塊45，用于在上線消息推送失敗時(shí)，通過(guò)服務(wù)器以向用戶發(fā)送短信消息的方式通知客戶。

綜上，本發(fā)明將多推送方案同時(shí)集成，極大的提高了常規(guī)方案消息到達(dá)率；進(jìn)一步地，使用SharedPreferences的鍵值對(duì)來(lái)存儲(chǔ)數(shù)據(jù)，巧妙的使用消息tag和鍵值對(duì)中的鍵的唯一性，能夠提高識(shí)別消息是否處理過(guò)的效率。進(jìn)一步地，通過(guò)EventBus來(lái)進(jìn)行消息轉(zhuǎn)發(fā)，屏蔽了常規(guī)廣播消息的很多弊端，優(yōu)勢(shì)明顯；且在極端情況下無(wú)法進(jìn)行推送時(shí)，使用短信對(duì)整個(gè)方案進(jìn)行補(bǔ)充，確保消息一定能夠到達(dá)用戶。

應(yīng)當(dāng)理解的是，對(duì)本領(lǐng)域普通技術(shù)人員來(lái)說(shuō)，可以根據(jù)上述說(shuō)明加以改進(jìn)或變換，而所有這些改進(jìn)和變換都應(yīng)屬于本發(fā)明所附權(quán)利要求的保護(hù)范圍。