本發(fā)明涉及移動終端與服務(wù)端的心跳包發(fā)送領(lǐng)域，具體涉及一種動態(tài)自適應(yīng)心跳發(fā)送方法及系統(tǒng)。

背景技術(shù)：

服務(wù)器和客戶端(移動終端設(shè)備，例如手機、平板電腦等)進行通信時，為了保證客戶端和服務(wù)器長時間保持連接，以便服務(wù)器能夠即時給客戶端推送消息，一般通過心跳包(客戶端和服務(wù)器間定時通知對方自己狀態(tài)的一個自己定義的命令字，按照一定的時間間隔發(fā)送，類似于心跳，所以叫做心跳包)維持客戶端與服務(wù)器之間的長期通信。常規(guī)的心跳包為固定發(fā)送時間，例如客戶端每隔500毫秒發(fā)送一次心跳包與服務(wù)器進行通信。

但是，由于客戶端在實際使用中的網(wǎng)絡(luò)類型(例如移動、聯(lián)通、電信)和網(wǎng)絡(luò)環(huán)境不同網(wǎng)絡(luò)環(huán)境(2G/3G/4G/WIFI)，而不同網(wǎng)絡(luò)類型和網(wǎng)絡(luò)環(huán)境斷開通信后重新連接的超時時間不同，因此為了兼容不同網(wǎng)絡(luò)類型和網(wǎng)絡(luò)環(huán)境的超時時間，需要根據(jù)最短超時時間來設(shè)置心跳包的發(fā)送時間(若心跳包的發(fā)送時間設(shè)置較低可能會導(dǎo)致部分網(wǎng)絡(luò)環(huán)境下客戶端與服務(wù)器斷開連接)，進而使得心跳包的發(fā)送時間過高。

進一步，由于每次發(fā)送心跳包均會消耗固定的網(wǎng)絡(luò)流量和電能，因此長期按照較高的發(fā)送時間發(fā)送心跳包，會消耗大量的網(wǎng)絡(luò)流量和電能，進而極大的降低了用戶體驗和客戶端性能。

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

針對現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明解決的技術(shù)問題為：針對不同的網(wǎng)絡(luò)環(huán)境，測試并使用合適的心跳包發(fā)送時間，本發(fā)明測試出的心跳包發(fā)送時間，能夠在保證最低時間下成功發(fā)送心跳包的同時，避免客戶端與服務(wù)器因為心跳包發(fā)送時間過長而導(dǎo)致超時的問題發(fā)生，進而降低心跳包的發(fā)送次數(shù)，顯著節(jié)省了客戶端的網(wǎng)絡(luò)流量和電能，提高了用戶體驗和客戶端性能。

為達到以上目的，本發(fā)明提供的動態(tài)自適應(yīng)心跳發(fā)送方法，包括以下步驟：

S1：當(dāng)客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境發(fā)送變化時，獲取變化之后的網(wǎng)絡(luò)環(huán)境，轉(zhuǎn)到S2；

S2：判斷客戶端中是否存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，若是，轉(zhuǎn)到S6，否則轉(zhuǎn)到S3；

S3：建立客戶端與服務(wù)器之間的連接，設(shè)置deltTime為50～200ms/次，轉(zhuǎn)到S4；

S4：客戶端根據(jù)deltTime向服務(wù)器發(fā)送測試消息，判斷測試消息是否發(fā)送成功，若是，增加deltTime的時長后重新執(zhí)行S4，否則確認(rèn)測試消息發(fā)送超時，轉(zhuǎn)到S5；

S5：將測試消息發(fā)送超時前一次設(shè)置的deltTime，作為當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間并保存后，重新執(zhí)行S2；

S6：根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，向服務(wù)器發(fā)送心跳包。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點在于：

本發(fā)明針對網(wǎng)絡(luò)環(huán)境的不同動態(tài)測試并使用適宜心跳包發(fā)送時間，測試心跳包發(fā)送時間不需要使用網(wǎng)絡(luò)。測試的心跳包發(fā)送時間時，采用設(shè)置較小的初始發(fā)送時間后逐步向上增加的方式進行測試，進而使得測試得到的心跳發(fā)送時間，能夠在保證最低時間下成功發(fā)送心跳包的同時，避免客戶端與服務(wù)器因為心跳包發(fā)送時間過長而導(dǎo)致超時的問題發(fā)生。

有鑒于此，與現(xiàn)有技術(shù)中發(fā)送時間過長或過段的心跳包發(fā)送時間相比，本發(fā)明會根據(jù)不同的網(wǎng)絡(luò)環(huán)境，測試并使用合適的心跳包發(fā)送時間，進而在保證客戶端與服務(wù)器長期連接的情況下，降低心跳包的發(fā)送次數(shù)，顯著節(jié)省了客戶端的網(wǎng)絡(luò)流量和電能，提高了用戶體驗和客戶端性能。

附圖說明

圖1為本發(fā)明實施例中的動態(tài)自適應(yīng)心跳發(fā)送方法的流程圖。

具體實施方式

以下結(jié)合附圖及實施例對本發(fā)明作進一步詳細說明。

參見圖1所示，本發(fā)明實施例中的動態(tài)自適應(yīng)心跳發(fā)送方法，包括以下步驟：

S1：當(dāng)客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境發(fā)送變化時，獲取變化之后的網(wǎng)絡(luò)環(huán)境，轉(zhuǎn)到S2。當(dāng)客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境未發(fā)生變化、且首次使用時，直接獲取客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境，轉(zhuǎn)到S2。

S1中獲取變化之后的網(wǎng)絡(luò)環(huán)境的原理為：在Android中網(wǎng)絡(luò)環(huán)境的變化系統(tǒng)是通過廣播接口來進行暴露的，若想要獲取變化后的網(wǎng)絡(luò)環(huán)境，則需要監(jiān)聽系統(tǒng)網(wǎng)絡(luò)廣播，一旦有廣播有消息過來說明當(dāng)前網(wǎng)絡(luò)環(huán)境發(fā)生了變化，即可通過廣播消息中攜帶的信息解析出當(dāng)前的網(wǎng)絡(luò)環(huán)境。

S1中獲取變化之后的網(wǎng)絡(luò)環(huán)境的具體流程為：

S101：通過調(diào)用registerReceiver函數(shù)注冊來監(jiān)聽客戶端的網(wǎng)絡(luò)廣播，網(wǎng)絡(luò)廣播發(fā)送有網(wǎng)絡(luò)變化消息時，轉(zhuǎn)到S102。

S102：獲取網(wǎng)絡(luò)變化消息中的網(wǎng)絡(luò)描述信息，解析網(wǎng)絡(luò)描述信息得到變化之后的網(wǎng)絡(luò)環(huán)境，實際應(yīng)用中的具體方法為：

通過函數(shù)getSystemService(Context.CONNECTIVITY_SERVICE)來獲取到當(dāng)前客戶端的ConnectivityManager連接管理者類。

調(diào)用管理者類中的getActiveNetworkInfo函數(shù)來獲取網(wǎng)絡(luò)變化消息中的網(wǎng)絡(luò)信息結(jié)構(gòu)體NetInfo，獲取NetInfo中的當(dāng)前網(wǎng)絡(luò)的描述信息。

調(diào)用NetInfo中的getType函數(shù)，返回描述信息中攜帶的變化之后的網(wǎng)絡(luò)環(huán)境，網(wǎng)絡(luò)環(huán)境分為下面幾類：

NETWORK_CLASS_2_G：當(dāng)前網(wǎng)絡(luò)環(huán)境是2G網(wǎng)絡(luò)；

NETWORK_CLASS_3_G：當(dāng)前網(wǎng)絡(luò)環(huán)境是3G網(wǎng)絡(luò)；

NETWORK_CLASS_4_G：當(dāng)前網(wǎng)絡(luò)環(huán)境是4G網(wǎng)絡(luò)；

TYPE_WIFI：當(dāng)前網(wǎng)絡(luò)環(huán)境是WIFI網(wǎng)絡(luò)。

S2：判斷客戶端中是否存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，若是，則轉(zhuǎn)到S6，否則轉(zhuǎn)到S3。

S2的具體流程為：從SharedPreferences文件中讀取當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，SharedPreferences是Android平臺上一個輕量級的存儲類，用來保存應(yīng)用的一些常用配置，比如Activity(界面)狀態(tài)，Activity暫停時，將此activity的狀態(tài)保存到SharedPereferences中；當(dāng)Activity重載，系統(tǒng)回調(diào)方法onSaveInstanceState時，再從SharedPreferences中將值取出。由于SharedPreferences的存儲是根據(jù)鍵值對來進行存儲的，因此讀取時只需要傳入當(dāng)前網(wǎng)絡(luò)環(huán)境對應(yīng)的鍵就可以讀取到相應(yīng)的心跳包發(fā)送時間。

網(wǎng)絡(luò)環(huán)境對應(yīng)的鍵包括：

NET_2G:2G網(wǎng)絡(luò)環(huán)境下的心跳值；

NET_3G:3G網(wǎng)絡(luò)環(huán)境下的心跳值；

NET_4G:4G網(wǎng)絡(luò)環(huán)境下的心跳值；

NET_WIFI:WIFI網(wǎng)絡(luò)環(huán)境下的心跳值。

若SharedPreferences文件之前已經(jīng)存儲過該發(fā)送時間，那么就能夠并返回該發(fā)送時間，即存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，直接轉(zhuǎn)到S6；若SharedPreferences文件從未存儲過該發(fā)送時間，則返回的發(fā)送時間為空，即不存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，需要轉(zhuǎn)到S3。

S3：在客戶端上通過openUrlConnection函數(shù)建立與服務(wù)器之間的連接，設(shè)置deltTime(測試消息發(fā)送時間)為50～200ms/次(即間隔50～200ms發(fā)送一次測試消息，本實施例中為100ms/次)，轉(zhuǎn)到S4。

S3中deltTime設(shè)置條件為：由于無論哪種網(wǎng)絡(luò)環(huán)境下通常連接的超時時間都是秒級別的(一遍都是2-5秒左右)，因此deltTime一定要確保不會出現(xiàn)心跳超時，所以一定不能太大(太大可能第一次就出現(xiàn)超時，進而無法實現(xiàn)S3中的增加時長后的測試功能)，而且deltTime設(shè)置太大雖然能夠減少后續(xù)的重復(fù)測試次數(shù)，但是會降低測試精度。

與此同時，deltTime也不能設(shè)置太小，若太小雖然提升了測試進度，但是會增加后續(xù)的重復(fù)測試次數(shù)。因此，為了滿足重復(fù)測試次數(shù)和測試精度的平衡，本實施例將deltTime設(shè)置為100ms(一般情況下100ms是不會出現(xiàn)超時的)。

S4：客戶端根據(jù)deltTime向服務(wù)器發(fā)送測試消息(測試消息一般為基本信息，例如客戶端的描述信息等)，判斷測試消息是否發(fā)送成功(即服務(wù)器是否響應(yīng)測試消息)，若是，增加deltTime的時長后重新執(zhí)行S4，否則確認(rèn)測試消息發(fā)送超時，轉(zhuǎn)到S5。

S4中deltTime時長的增加方法為：增加時長后的deltTime＝增加時長前的+初始設(shè)置的deltTime。

S5：將測試消息發(fā)送超時前一次設(shè)置的deltTime作為timeOut-deltTime(當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間)，將timeOut-deltTime保存后重新執(zhí)行S2。

S5中將測試消息發(fā)送超時前一次設(shè)置的deltTime作為timeOut-deltTime的原因為：在保證最低時間下成功發(fā)送心跳包的同時，避免客戶端與服務(wù)器因為心跳包發(fā)送時間過長而導(dǎo)致超時的問題發(fā)生。

S5中timeOut-deltTime的保存方法為：將當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間寫入SharedPreferences文件中，詳細流程需要根據(jù)SharedPreferences的本質(zhì)(基于XML文件存儲key-value鍵值對數(shù)據(jù))制定，具體為：

S501：獲取客戶端中SharedPreferences的存儲接口：通過函數(shù)PreferenceManager.getDefaultSharedPreferences(Context)就能夠獲取到系統(tǒng)默認(rèn)的存儲接口實例sharedPreferences；

S502：通過sharedPreferences調(diào)用其中的edit()函數(shù)獲取到編輯接口editor；

S503：調(diào)用editor中的putInt函數(shù)(功能：存儲一個整形數(shù)據(jù))將timeOut-deltTime存儲到編輯接口中：

S504：通過commit函數(shù)將editor中的timeOut-deltTime進行提交，客戶端將提交后的timeOut-deltTime寫入SharedPreferences文件。

S6：客戶端根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，向服務(wù)器發(fā)送心跳包。

本發(fā)明實施例提供的動態(tài)自適應(yīng)心跳發(fā)送系統(tǒng)，包括設(shè)置于客戶端上的網(wǎng)絡(luò)環(huán)境獲取模塊、心跳包發(fā)送時間確認(rèn)模塊、測試參數(shù)設(shè)置模塊、心跳包發(fā)送時間測試模塊、心跳包發(fā)送時間儲存模塊和心跳包發(fā)送模塊。

網(wǎng)絡(luò)環(huán)境獲取模塊用于：當(dāng)客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境發(fā)送變化時，獲取變化之后的網(wǎng)絡(luò)環(huán)境，向心跳包發(fā)送時間確認(rèn)模塊發(fā)送心跳包發(fā)送時間確認(rèn)信號。當(dāng)客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境未發(fā)生變化時，直接獲取客戶端當(dāng)前使用的網(wǎng)絡(luò)環(huán)境，向心跳包發(fā)送時間確認(rèn)模塊發(fā)送心跳包發(fā)送時間確認(rèn)信號。

心跳包發(fā)送時間確認(rèn)模塊用于：收到心跳包發(fā)送時間確認(rèn)信號后，判斷客戶端中是否存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，若是，則向心跳包發(fā)送模塊發(fā)送心跳包發(fā)送信號，否則向測試參數(shù)設(shè)置模塊發(fā)送心跳包發(fā)送時間測試信號；具體流程為：

在Android的SharedPreferences文件中，傳入當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間鍵，SharedPreferences文件返回與當(dāng)前心跳包發(fā)送時間鍵對應(yīng)的網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間；若心跳包發(fā)送時間不為空，則確定存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間；若心跳包發(fā)送時間為空，則確定不存在當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間。

測試參數(shù)設(shè)置模塊用于：收到心跳包發(fā)送時間測試信號后，建立客戶端與服務(wù)器之間的連接，設(shè)置deltTime為50～200ms/次，向心跳包發(fā)送時間測試模塊發(fā)送心跳包發(fā)送時間測試信號。

心跳包發(fā)送時間測試模塊用于：收到心跳包發(fā)送時間測試信號后，根據(jù)deltTime向服務(wù)器發(fā)送測試消息，判斷測試消息是否發(fā)送成功，若是，增加deltTime的時長后(增加時長后的deltTime＝增加時長前的+初始設(shè)置的deltTime)，重新向心跳包發(fā)送時間測試模塊發(fā)送心跳包發(fā)送時間測試信號，否則確認(rèn)測試消息發(fā)送超時，向心跳包發(fā)送時間儲存模塊發(fā)送心跳包發(fā)送時間儲存信號。

心跳包發(fā)送時間儲存模塊用于：收到心跳包發(fā)送時間儲存信號后，將測試消息發(fā)送超時前一次設(shè)置的deltTime，作為當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間并保存后(將網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間寫入SharedPreferences文件中)，重新向心跳包發(fā)送時間確認(rèn)模塊發(fā)送心跳包發(fā)送時間確認(rèn)信號。

心跳包發(fā)送模塊用于：收到心跳包發(fā)送信號后，根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境的心跳包發(fā)送時間，向服務(wù)器發(fā)送心跳包。

進一步，本發(fā)明不局限于上述實施方式，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也視為本發(fā)明的保護范圍之內(nèi)。本說明書中未作詳細描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。