本發明涉及互聯網消息推送領域，尤其涉及一種關注主播上線提醒方法及系統。

背景技術：

傳統方案中關于關注主播上線提醒方法中，通常是通過心跳或者第三方推送來推送消息。當接收到服務器傳送過來的消息后客戶端進行提示關注主播上線提醒。傳統方案有一個很大的缺陷。對于使用心跳保持客戶端與服務器的長連接的方案中，當客戶端在后臺運行的時候，系統會發現客戶端在后臺一直發送心跳操作，所以系統很可能會將該應用進行殺掉。這樣就中斷了客戶端和服務器的連接，一旦客戶端和服務器的連接中斷，此時客戶端就無法接收到服務器推送過來的消息了。

對于使用第三方推送的方案，由于第三方推送的SDK做了很多的保活優化手段，確保第三方推送SDK能夠保活，不會輕易被系統殺死。但是在部分手機上依舊會被系統殺死，導致推送消息無法進行接收。

技術實現要素：

本發明要解決的技術問題在于針對現有技術中推送消息容易被系統殺死的缺陷，提供一種提高消息推送成功率的關注主播上線提醒方法及系統。

本發明解決其技術問題所采用的技術方案是：

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

通過集成多個消息推送平臺向客戶端推送用戶所關注主播的上線消息，該上線消息為具有唯一標識的上線消息；

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

消息通知模塊通過通知欄發送該上線消息至客戶端。

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

若客戶端的消息推送進程被系統關閉，則重新向客戶端推送重新啟動的模塊。

本發明所述的方法中，所述上線消息包括唯一標識和消息內容，消息內容相同的上線消息的唯一標識是相同的。

本發明所述的方法中，所述指定存儲空間為SharedPreferences存儲模塊，將上線消息保存到SharedPreferences的鍵值對中；其中鍵是上線消息的唯一標識，值是消息的具體內容。

本發明所述的方法中，具體通過安卓系統中的EventBus來發送上線消息。

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

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

在Android系統中注冊靜態廣播，接收網絡變化的回調消息；

根據接收的網絡變化的回調消息判定網絡狀態，若網絡連接正常，則重新向客戶端推送重新啟動消息推送模塊；若網絡斷開連接了，則不做任何處理。

本發明還提供一種關注主播上線提醒系統，包括：

平臺集成模塊，用于集成多個消息推送平臺向客戶端推送用戶所關注主播的上線消息，該上線消息為具有唯一標識的上線消息；

消息過濾模塊，用于判斷該上線消息是否已經存在于服務器的指定存儲空間，若是，則舍棄該上線消息；若否，則將該上線消息發送到消息通知模塊，并將該上線消息存儲到所述指定存儲空間；

消息通知模塊，用于通過通知欄發送該上線消息至客戶端。

本發明所述的系統中，該系統還包括：

推送恢復模塊，用于在客戶端的消息推送進程被系統關閉時，重新向客戶端推送重新啟動的模塊。

本發明產生的有益效果是：本發明通過集成多推送平臺向客戶端推送用戶所關注主播的上線消息，極大的提高了常規方案消息到達率。通過對消息的過濾，避免了消息的重復發送。

進一步地，使用SharedPreferences的鍵值對來存儲數據，巧妙的使用消息唯一標識和鍵值對中的鍵的唯一性，能夠提高識別消息是否處理過的效率。

進一步地，通過EventBus來進行消息轉發，屏蔽了常規廣播消息的很多弊端，優勢明顯。極端情況下無法進行推送時，使用短信對該方案進行補充，確保消息一定能夠到達用戶。

附圖說明

下面將結合附圖及實施例對本發明作進一步說明，附圖中：

圖1是本發明實施例注主播上線提醒方法的流程圖；

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

圖3是本發明實施例廣播監聽的流程圖；

圖4是本發明實施例注主播上線提醒系統的結構示意圖；

圖5是本發明另一實施例注主播上線提醒系統的結構示意圖。

圖6是本發明第三實施例注主播上線提醒系統的結構示意圖。

具體實施方式

為了使本發明的目的、技術方案及優點更加清楚明白，以下結合附圖及實施例，對本發明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅用以解釋本發明，并不用于限定本發明。

先對所涉及的專業名詞進行解釋：

SharedPreferences：是Android平臺上一個輕量級的存儲類，用來保存應用的一些常用配置。

SDK：軟件開發工具包(SDK：Software Development Kit)一般是軟件工程師為特定的軟件包、軟件框架、硬件平臺、操作系統等建立應用軟件時的開發工具的集合。

EventBus：一種消息傳輸總線。

本發明提出了一套提高消息推送成功率的方案，通常較常規做法是集成一個推送平臺，但是無法保證該推送平臺不會被系統殺死。本發明中集成多個推送平臺，將多個推送平臺全部集成到應用中，然后對推送消息進行過濾處理，任何時候只要有一個推送平臺是存活狀態，就能夠接受到推送消息。這樣就能夠很大程度上的提升消息的到達率，從而能夠及時的將主播上線的消息推送給用戶。

在某些極端情況下如果發現所有的推送平臺都被系統殺死掉了，推送都是失敗的時候，會通過短信形式來告知用戶主播上線的消息。

通過本發明的技術實施，基本可以確保消息能夠100％被用戶接收到，這樣就能夠保證用戶不會錯過所關注主播的上線消息。

如圖1所示，本發明的一個實施例關注主播上線提醒方法主要包括以下步驟：

S101、通過集成多個消息推送平臺向客戶端推送用戶所關注主播的上線消息，該上線消息為具有唯一標識的上線消息；

S102、判斷該上線消息是否已經存在于服務器的指定存儲空間，若是，則轉入執行步驟S104；若否，則轉入執行步驟S103；

S103、舍棄該上線消息；

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

S105、消息通知模塊通過通知欄發送該上線消息至客戶端。

其中，步驟S101中，對于多個消息推送平臺的集成，不同平臺集成方式大同小異，本發明實施例列舉其中一種舉例說明(個推推送)，其他集成方式與此類似方式進行集成。本發明通過集成多個推送平臺的SDK來提高消息推送的成功率，通過多個SDK同時對消息進行推送，任何時候只要系統中任何一個推送SDK是存活狀態，就能夠接收到服務器推送過來的主播上線的消息。

本發明由于集成了多個推送SDK，每個SDK都有自己特有的一套保活方式，當其中一個推送SDK失效后，只要有任何一個推送SDK是存活狀態，依舊能夠很好的接受到服務器傳遞過來的主播上線的消息信息。

由于集成方法是一個公開通用的技術，本發明實施例中對此僅作簡要概括：

1)在開發者平臺創建應用說明

2)資源文件導入和配置文件引入

3)配置相關權限信息

4)導入通知欄圖標

5)初始化SDK

6)資源精簡配置

7)確認Gradle配置

8)測試

整個集成過程大體分為上述的8個步驟，每個步驟都完成其中的相應過程，具體每一步驟的細節針對每個平臺可能會有一定的差異性，這些集成過程都是公開的方法。按照對應的平臺的集成文檔對此進行集成處理即可。

步驟S102-104是對信息的過濾。為了提高推送的成功率，本發明實施例中每次消息都是通過多個平臺進行統一發送的。這樣就會造成一個問題，那就是每次都可能接收到很多條重復的消息。因此需要對多條重復的消息進行過濾處理。

過濾消息方法具體為：

為了能夠將消息進行過濾處理，本發明實施例中設計消息的時候給消息加入了一個tag標簽，這個tag標簽用于唯一表示一條消息。

消息的結構體形式如下：

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

Message：表示消息內容

由于同時集成了多個推送模塊，并且消息是推送模塊進行同時發送的。也就是說我們可能在同一時間內同時收到很多條相同的消息。

為了能夠用于區分消息是否被發送過，可將已經處理過的消息會被保存到SharedPreferences存儲的鍵值對中。此處對于鍵值對的設計有一定的巧妙性，優于消息的Tag是唯一的，在鍵值對的存儲中鍵也需要是唯一的。這樣就剛好可以將已經處理過的消息通過SharedPreferences來進行存儲，其中SharedPreferences存儲的鍵是消息的Tag，值是消息Message的內容。

當消息過來的時候，首先會去SharedPreferences中存儲的鍵值對中去查詢Tag所對應的消息。

如果通過鍵值對獲取到了Tag所對應的消息，說明該消息已經被處理過。此時可以舍棄掉該條消息，不對該條消息進行處理。

如果通過鍵值對獲取Tag所對應的消息為空，說明該消息沒有被處理過。此時我們就可以將該消息發送到UI層進行通知的彈出等處理。

本發明實施例使用SharedPreferences的鍵值對來存儲數據，巧妙的使用消息tag和鍵值對中的鍵的唯一性，能夠提高識別消息是否處理過的效率。

步驟S105是消息的發送，主要是將消息轉發到UI層(User Interface)來進行處理，常規的消息轉發的方式通常是廣播形式來進行轉發。本發明則優選通過EventBus來進行轉發。

傳統廣播轉發消息存在的問題：

1、廣播消息的轉發，消息無法保證及時到達，會存在一定的延時性。由于系統所有的廣播都是通過一個消息處理模塊進行處理的，如果系統中廣播消息過多的時候，就會出現消息阻塞，導致消息到達速度慢的問題。

2、廣播下次的轉發使用起來復雜，廣播轉發一定存在三個部分，其一是發送消息，其二是注冊消息，其三是接受消息。這三個部分全部進行整合后才能夠正確的接受到廣播發送過來的消息。使用起來步驟較多且復雜。

選擇EventBus的優勢：

1、EventBus傳遞消息方便快捷，使用起來非常簡潔。

2、EventBus僅僅處理自己發送模塊發送的消息，所有EventBus消息處理的數量上來說是小于廣播消息的處理數量的，所以速度上會比廣播快。

3、Event不需要注冊，消息的接收和發送的綁定關系是通過消息體來進行直接綁定的，也就是說發送模塊只需要關注發送任務，接收模塊只需要關注接收和處理任務，使得整個代碼可維護性會更高。

使用EventBus來發送消息是通過sendEvent函數來進行消息的發送的。接收函數是onEventHandler來接收處理發送過來的消息體。

當接收到主播上線的消息后，就可以通過通知欄發送一條主播上線的消息給用戶，提示用戶主播上線的消息。

本發明實施例通過EventBus來進行消息轉發，屏蔽了常規廣播消息的很多弊端，優勢明顯。

如圖2所示，本發明實施例還包括推送恢復步驟，具體為：

S106、判斷客戶端的消息推送進程是否被系統關閉；若是，則執行步驟S107；

S107、重新向客戶端推送重新啟動的模塊。即激發客戶端的消息推送進程重新開啟。

推送恢復的主要功能是當系統將推送模塊殺死的時候，找機會將推送SDK重新啟動。

由于推送一定會使用到網絡，所以上述推送恢復步驟主要功能是通過監聽系統網絡變化，如果方向系統網絡鏈接上的時候會主動再次啟動推送SDK，這樣就能夠大大的提升推送SDK長期存活的概率。

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

S301、在Android系統中注冊靜態廣播，接收網絡變化的回調消息；

S302、根據接收的網絡變化的回調消息判定網絡狀態，若網絡斷開連接了，則不做任何處理；若網絡連接正常，則執行步驟S303；

S303、重新向客戶端推送重新啟動消息推送模塊；

接下來詳細描述上述的執行流程：

步驟S301主要為廣播的監聽：

在Android系統中廣播分為靜態廣播和動態廣播兩種類型，

靜態廣播：可以在應用程序未啟動的時候接受和處理廣播任務。

動態廣播：必須得要應用程序啟動的時候才能夠接收，應用程序退出了就不能接收了。

由于本發明目的期望最大程度上的激活推送SDK，所以本發明實施例選用靜態廣播來進行注冊。

步驟S302主要判斷網絡連接狀態：

注冊網絡變化的廣播后，就能夠接收到網絡變化的回調消息。系統將所有網絡信息封裝到NetworkInfo類中，NetworkInfo類包含了當前網絡的相關信息。接收到網絡變化的回調消息后，可以去判定網絡狀態。

判斷網絡狀態的方法是調用NetworkInfo中的isConnected方法來判定當前網絡是否連接狀態。如果isConnected返回的是真，說明網絡鏈接上了，此時我們需要重啟推送SDK框架。如果isConnected返回的是假，說明此時網絡斷開連接了，此時可不做任何處理。

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

如果檢測到網絡連接上我們需要重啟推送SDK，推送SDK模塊如果啟動狀態下，我們再次調用啟動函數startPush不會再次重啟而是繼續運行。如果推送SDK模塊處于停止狀態下，調用startPush，此時會啟動該推送SDK模塊。

通過推送恢復的設計，能夠將被系統殺死的推送進程進行再次激活，這種激活方式可以確保推送SDK能夠再次被使用，大大提高了消息傳遞的成功率。

極端情況下無法發送消息時的處理方案：如果在某些極端情況下導致上述推送SDK全軍覆沒時，客戶端推送SDK停止運行的時候，服務器端發送推送請求，由于沒有接收到SDK相關的反饋信息，服務器端會有推送超時信息接收。此時服務器就知道整個過程是失敗的。如果失敗了，此時會通過服務器來向用戶發送短信消息的方式進行通知，確保主播上線消息能夠100％到達用戶。

此部分僅僅作為本發明的輔助處理方案，確保能夠在極端情況下導致無法接收到消息的時候，還可以通過短信通知的方式來告知用戶主播上線的消息。

為實現上述實施例的關注主播上線提醒方法，本發明還提供了關注主播上線提醒系統，如圖4所示，包括：

平臺集成模塊41，用于集成多個消息推送平臺向客戶端推送用戶所關注主播的上線消息，該上線消息為具有唯一標識的上線消息；

消息過濾模塊42，用于判斷該上線消息是否已經存在于服務器的指定存儲空間，若是，則舍棄該上線消息；若否，則將該上線消息發送到消息通知模塊，并將該上線消息存儲到所述指定存儲空間；

消息通知模塊43，用于通過通知欄發送該上線消息至客戶端。

如圖5所示，在上述實施例的基礎上，該系統還包括：

推送恢復模塊44，用于在客戶端的消息推送進程被系統關閉時，重新向客戶端推送重新啟動的模塊。

如圖6所示，在上述實施例的基礎上，該系統還包括短消息發送模塊45，用于在上線消息推送失敗時，通過服務器以向用戶發送短信消息的方式通知客戶。

綜上，本發明將多推送方案同時集成，極大的提高了常規方案消息到達率；進一步地，使用SharedPreferences的鍵值對來存儲數據，巧妙的使用消息tag和鍵值對中的鍵的唯一性，能夠提高識別消息是否處理過的效率。進一步地，通過EventBus來進行消息轉發，屏蔽了常規廣播消息的很多弊端，優勢明顯；且在極端情況下無法進行推送時，使用短信對整個方案進行補充，確保消息一定能夠到達用戶。

應當理解的是，對本領域普通技術人員來說，可以根據上述說明加以改進或變換，而所有這些改進和變換都應屬于本發明所附權利要求的保護范圍。