,,, ,

(蘇州大學 計算機科學與技術學院,江蘇 蘇州 215006)

0 概述

即時通信(Instant Messaging,IM)是目前移動互聯(lián)領域的研究熱點[1-3]。它主要基于互聯(lián)網,實現(xiàn)通信雙方的消息實時傳遞,具有快速、高效、實時等信息特點[4]。它不同于傳統(tǒng)的電子郵件通信,需要幾個小時或者幾天時間才能有對應的信息反饋。即時信息已經部分取代了電子郵件的個人信息交流功能。近年來,隨著移動應用市場的擴大,移動社交服務越來越成為移動用戶不可缺少的功能。

為了實現(xiàn)即時消息通信,傳統(tǒng)的有pull方法[5-6]通過每個終端定時去服務器上掃描,有新數(shù)據時,移動客戶端就將數(shù)據pull下來,這樣就實現(xiàn)了在一定延遲內數(shù)據是最新的,人們常常也把這種方式叫做“輪詢”。但是這種方法在移動端實現(xiàn)的話,會存在大量流量和電量的消耗。針對pull方法的不足,由服務器主動推送的push方法成為了主流[7],push方法要求客戶端與服務器端維持一條可實時交互信息的連接通道,也稱為長連接。但由于運營商計時關閉連接的服務架構,移動端長連接持久性的維持必須依賴于客戶端的心跳機制(Heartbeat Mechanism)[8-9],這一機制給客戶端設定了規(guī)律性的定時操作,讓長連接得以存在和維持。

目前國內主流即時通信應用(微信、QQ、陌陌、WhatsApp)的內部實現(xiàn)都是基于push的方法[10-12],而隨著這些應用的增多,其內部的心跳機制也會不斷加大安卓系統(tǒng)的資源消耗[13-15]。蘋果iOS在系統(tǒng)內部統(tǒng)一了心跳機制的間隔,因此,沒有相應的資源過度消耗問題。而安卓由于其開源開放性,第三方ROM的增多,導致安卓系統(tǒng)不能很好地統(tǒng)一系統(tǒng)內部處理心跳的機制,即使后來谷歌推出針對心跳的GCM和C2DM服務,也因谷歌撤離中國大陸而無法在國內推行。

目前安卓心跳優(yōu)化方案主要分為2個方向:減少能量消耗,也就是減少不必要的心跳激活,對于多應用而言,最直接的方法就是進行心跳同步,達到與蘋果iOS系統(tǒng)相近的效果,這是比較困難的,這通常需要從系統(tǒng)層面實現(xiàn)或者制定特定的心跳同步協(xié)議來完成。提高能量的利用率,因為每次心跳都會產生尾部能量浪費,而將這浪費的能量用于傳輸有價值的數(shù)據則就可以提高能量利用率,達到性能的提升。以上述研究為基礎,本文方法不需要從系統(tǒng)層面完成或者制定特定協(xié)議來解決同步問題,而是完全基于現(xiàn)有的應用通信方式,并僅從應用層實現(xiàn)心跳捕獲與同步,達到一定程度上的性能優(yōu)化。對安卓平臺上應用的心跳過程進行深度的檢測、分析,結合Xposed框架完成優(yōu)化目的,提高安卓端手機用戶體驗。

1 即時通信應用的心跳檢測

對于即時通信應用心跳的普遍存在性,本文主要通過抓包實驗來證明。在實驗上本文主要以控制單一變量法來實施。實驗系統(tǒng)是原生Android4.4系統(tǒng),測試硬件為Google Nexus7 2012版平板。測試對象為Wechat6.3、QQ6.3、Momo6.7、WhatsApp2.0。

本文主要采用Linux中的Tcpdump命令來實現(xiàn)Android端數(shù)據包的抓取,最終得到以pcap為后綴的文件,再利用Wireshark工具篩選出所有應用與對應的服務器交互的所有數(shù)據包。

以QQ的抓包數(shù)據為例,趨于穩(wěn)定時數(shù)據包交互時間情況如表1所示,此表同時也列出計算后數(shù)據包與前數(shù)據包的時間差。

表1 QQ數(shù)據包交互信息

從表1可以看出,QQ應用越趨于后面穩(wěn)定狀態(tài)時,時間之差也越趨于相同的270 s,根據多次實際數(shù)據監(jiān)測和觀察,可以確定此數(shù)據交互即為QQ的心跳包,并且QQ的心跳間隔為270 s。

本文根據相同的方式,對Wechat5.3、Momo6.7、Wechat6.3、QQ6.3、WhatsApp2.0等版本應用測試,并總結出結果數(shù)據,繪制柱狀圖如圖1所示。圖中展示了各個應用的心跳周期都很短,都在5 min之內,這導致多種App心跳在系統(tǒng)休眠情況下還是會喚醒CPU繼續(xù)執(zhí)行網絡請求,并且由于心跳間隔的不同,多種App心跳并不能被系統(tǒng)策略統(tǒng)一,從而也會頻繁喚醒CPU處理網絡數(shù)據請求。整個流程如圖2所示,這對用戶手機的內存、電量、流量都是一種巨大的挑戰(zhàn)。所以,本文期望設計如圖3所示的心跳流程,可以減小休眠喚醒操作,同時修改心跳間隔一致,這樣可利用系統(tǒng)自動調節(jié)功能在休眠后立即執(zhí)行心跳機制從而統(tǒng)一心跳觸發(fā)點,有利于節(jié)約手機資源。

圖1 各即時通信應用心跳周期

圖2 原始心跳流程

圖3 目標心跳設計流程

2 心跳機制對手機性能的影響分析

2.1 流量耗用檢測

對于流量的檢測,本文采用時間累積法檢測一定時間內的心跳流量消耗。監(jiān)測軟件是系統(tǒng)內置的流量監(jiān)控工具,表2統(tǒng)計了2 h時長內的流量消耗情況,并給出了每個App從開始時間至結束時間的總流量、前臺流量和后臺流量消耗情況。由于一開始后臺流量基數(shù)就大,因此結束時間的后臺消耗總流量也就大,但本文主要關注的是2個時間點流量消耗的差值,單個時間點的流量消耗是無意義的。從表中數(shù)據可知整個應用在測試中的流量消耗完全來自于后臺的流量交互,而在測試期間本文實驗完全杜絕其他一切信息交互,因此,不考慮其他因素的情況下,可將后臺流量消耗情況作為2 h測試期間的心跳通信的流量消耗總量。

表2 各即時通信應用流量消耗情況

2.2 電池電量檢測

安卓系統(tǒng)自帶電量的監(jiān)測工具只顯示消耗量最多的前幾位應用,而本文需要對各個目標應用的實際電量消耗情況進行詳細描述,因此,本文選擇了市面上使用比較廣泛的360電池管家應用作為應用耗電的主檢測程序,并以系統(tǒng)自帶監(jiān)測工具作為驗證和校驗的輔助工具。

電量的消耗也是具有時間跨度性的,并且真正的電量消耗并不能通過該軟件獲得到,所以,本文選擇在2 h的時間跨度上檢測應用占用CPU的時間長度作為應用耗電的評測指標,檢測主要根據結束時的CPU占時減去開始的CPU占時長度以得到檢測期間應用的CPU占用時長,其詳細檢測數(shù)據情況如表3所示。

表3 各應用占用CPU時長 s

從表3中可以看出,應用退出到后臺后也會占用這手機的CPU,繼續(xù)消耗著手機的電能,在沒有其他可視化數(shù)據流量交互的情況下,作為后臺唯一可產生網絡數(shù)據交互的機制,這些數(shù)據可作為應用的心跳進程產生的CPU操作時長,進而作為電量消耗的間接評估數(shù)據。

2.3 實驗分析與總結

本文通過2個實驗分別對4款即時通信應用的心跳線程資源消耗進行了檢測。在流量、電量上都存在比較高的資源耗損。而心跳的資源消耗是一種常駐消耗,常常在用戶不知情的情況下偷偷跑流量并蠶食著電量,所以,有必要對這些應用進行一些用戶可選擇性的限制操作,讓用戶在不愿意關閉應用的同時降低應用的資源消耗。

3 基于Xposed框架的性能優(yōu)化方案

通過抓包檢測了各個即時通信應用的心跳過程,證明了心跳機制在各種社交軟件中的普遍存在性以及后臺心跳線程的頻繁喚醒性,而第2節(jié)中,則監(jiān)測了多個IM應用對手機性能方面的影響,實驗數(shù)據也說明了心跳機制是一種常駐消耗。因此,如何降低心跳帶來的資源耗用大問題,是本節(jié)重點要解決的問題。

3.1 方案概述

針對心跳機制的優(yōu)化本文主要分為2個方面內容:

1)采用系統(tǒng)可自動調節(jié)定時器,并盡可能地設置最大時長。根據國內運營商情況,本文實驗設置5 min時長,從而減少單位時間內的心跳次數(shù),降低心跳頻繁度的開銷。并且以官方推薦的系統(tǒng)自動調節(jié)方法作為心跳喚醒的主要方法,替換一些精確而具有開銷大的方法實現(xiàn)。

2)另外就是修改因心跳而產生的后續(xù)資源消耗操作,比如心跳后常常產生的CPU喚醒或者屏幕喚醒等API調用,本文通過限制這些操作來達到節(jié)省這部分的資源耗用。還有Android系統(tǒng)為各個App提供的賬號同步策略,通常在國內基本不使用該策略機制,本文也實現(xiàn)該同步中方法的修改實現(xiàn),降低同步帶來的后臺服務開銷。

由于這些策略在有嚴格權限限制的開發(fā)平臺上是完全不能實現(xiàn)的,這涉及到第三方應用中代碼的修改與變更,一般的應用是完全沒有這種絕對修改的權限的。所以本文選擇在已ROOT的安卓系統(tǒng)平臺上利用Xposed,框架來達到修改優(yōu)化的目的。如圖4所示,該圖展示了方案實現(xiàn)的具體流程:在系統(tǒng)啟動后Xposed框架將修改jar包加入環(huán)境變量,然后各種應用啟動后都會被jar包中的方法所截取,通過框架接口就可以在截取的方法前后實現(xiàn)自己開發(fā)的代碼,而某個應用是否要修改完全由應用在用戶界面設置,本文根據應用包名進行匹配,匹配成功則進入應用內代碼的修改與替換,否則直接跳過該應用,以此達到對用戶需要修改的應用進行優(yōu)化的目的。

圖4 本文方案實現(xiàn)流程

Xposed框架入侵式的特點使得其需要特殊的ROOT系統(tǒng)環(huán)境,雖然要求比較特殊和苛刻,但其作為一種優(yōu)化方案,完全以用戶自身意愿決定,本文最終以App的形式呈現(xiàn)該解決方案,給用戶完全的自由度。

3.2 Xposed框架及心跳接口說明

Xposed框架是一款可以在不修改APK的情況下影響程序運行的框架服務,它是開源免費的,所以,有很多極客者基于該框架制作出許多強大的模塊,它的社區(qū)活躍度也越來越高,目前該框架已經可以支持最新的Android 6.0系統(tǒng)了。

Xposed框架主要以黑客技術侵入到安卓運行時引擎,由于Android系統(tǒng)中所有應用的首個啟動進程為“Zygote”,它是Android運行環(huán)境的核心,當手機啟動后就首先執(zhí)行/init.rc這個腳本,該腳本隨后執(zhí)行/system/bin/app_process可執(zhí)行文件,該可執(zhí)行文件就是產生“Zygote”進程之處。Xposed框架就將修改過的app_process復制到/system/bin下替換原來的app_process,修改的app_process包含了一個額外的jar包到classpath路徑里,因此,生成的“Zygote”進行就可以使用jar包里的方法了,所以基于Xposed框架就可以實現(xiàn)修改所有Android平臺的應用了。而要想實現(xiàn)優(yōu)化方案,必先了解官方對于心跳實現(xiàn)所提供的API接口,對于本文也正是要對以下一些接口類方法進行調整優(yōu)化的:

1)android.app.AlarmManager該類提供了系統(tǒng)級的定時服務,對于即時通信應用來說就是其內部心跳的觸發(fā)器。而心跳服務常使用該類的3個方法,分別為set(int,long,PendingIntent),setExact(int,long,PendingIntent)和setRepeating(int,long,long,Pending-Intent),前2個主要設置單次定時計劃任務,由于本文不能確定某些應用開發(fā)者使用什么方法定時心跳,所以本文也將此方法列入捕獲修改的隊列,第3個方法為設置計劃性重復任務方法,是心跳實現(xiàn)最常用的方式了,因而這是此部分主要優(yōu)化和修改之處。

2)android.os.PowerManager.WakeLoc該類是系統(tǒng)提供給應用開發(fā)者獲取運行鎖的服務類,在用戶設備息屏后,設備將進入休眠狀態(tài),應用要想運行必須要先獲得運行鎖,才能喚醒CPU進行相應的操作,這也就導致用戶即使將App退出到后臺,App還是可以通過喚醒鎖申請資源繼續(xù)工作。官方給出了獲得喚醒鎖的一致方法,如代碼所示。從中可以知道整個喚醒鎖的獲得先通過PowerManager.newWakeLock()方法獲得WakeLock的實例,再通過acquire()獲得運行CPU,所以,本文要進行修改的方法為newWakeLock(int,String),acquire()和其重載方法acquire(long),其代碼結構如下:

//start

PowerManager pm = (PowerManager)

getSystemService(Context.POWER_SERVICE);

PowerManager.WakeLock wl =

pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_

LOCK,"My Tag");

wl.acquire();

//..screen will stay on during this section..

//end

3)android.content.ContentResolver通常大家理解該類是通過ContentProvider,因為ContentProvider是Android的四大組件之一,是大家常常用到的用于各個應用程序之間共享數(shù)據的服務類,而ContentResolver就是操作ContentProvider中數(shù)據的具體操作方式。但是本文在此處涉及的是ContentResolver另外功能—本地賬戶同步。因此本文主要關注其2類方法,一種是setSyncAutomatically(Account,String,Boolean)該方法是設置賬戶是否自動同步。另外一種是requestSync(),它有3種重載方法分別為requestSync(Account,Strin-g,Bundle)、requestSync(SyncRequest)、requestSync(A-ccount,String,Bundle,Long),它們的作用是主動請求直接同步。

Android系統(tǒng)為開發(fā)者提供了豐富的心跳方面的類接口,開發(fā)者也將以官方API作為本文方案實現(xiàn)的切入點,通過修改存在一定資源耗費的方法來完成心跳相關的性能優(yōu)化。

3.3 iHeart應用的實現(xiàn)

本節(jié)所要開發(fā)的應用在正常的普通Android應用層上是很難實現(xiàn)的,所以,本文方法借助了Xposed框架的入侵功能來實現(xiàn)此解決方案。要達到修改第三方應用方法的目的,本文方案就必須要從應用的鑒別和應用方法的獲取上下手,下面分別從應用包名的鑒別和心跳相關方法的截獲兩方面來分析實現(xiàn)。

1)應用包名的鑒別

Xposed框架為應用開發(fā)者提供的最核心類為IXpo-sedHookLoadPackage接口,該接口的抽象方法是整個App的修改入口,其原型如下:public void handleLoadPackage(XC_LoadPackage.LoadPackageParam lpparam),該抽象方法只有一個參數(shù),其類型XC_LoadPackage.L-oadPackageParam類,該類就是本方案鑒別每個應用的唯一性的來源,因為應用只能通過lpparam.packageName來獲得Android系統(tǒng)加載的應用包名,當用戶確定了某些需要修改的App后,根據lpparam.packageName的值與每個需要修改的App的包名對比,如果相同,那么繼續(xù)進行下面的方法截獲功能,如果不同那么不做任何操作。包名的鑒別是本方案整個應用的入口之處,也是之后的功能操作得以運行的前提保障。

2)心跳相關方法的截獲

當鑒別了符合條件的應用包名后,就可以進入真正的方法修改了,在修改之前先要抓取(Hook)到需要修改的方法。Xposed框架通過XposedHelpers類提供了一個靜態(tài)的Hook方法—findAndHookMethod,該方法的原型為:public static Unhook findAndHookMethod(String className,ClassLoader classLoader,String methodName,Object…parameterTypesAndCallback),該方法的第1個參數(shù)為類名,是開發(fā)者想要抓取的方法的承載類,第2個參數(shù)為類加載器,這個為固定的,通過上節(jié)的包獲取類lpparam.classLoader獲得類加載器,第3個參數(shù)為本方案需要Hook住的方法名,這個就是iHeart要修改的目標方法了,第4個參數(shù)是Object數(shù)組,數(shù)組里要求按照順序包含目標方法的所有參數(shù)。通過此方法本應用就能輕易地抓取到所要修改的方法了。

在可以獲取到所需修改的方法后,開發(fā)者需要繼承XC_MethodHook,提供一個實例類,放在Object數(shù)組的最后一位參數(shù)里,這里本節(jié)的修改方法按照心跳觸發(fā)類AlarmManager、CPU喚醒類WakeLock和賬號同步方法類ContentResolver這3類展開。

1)心跳觸發(fā)類AlarmManager

該類里的set(interger,long,PendingIntent)和setExact(Interger,long,PendingIntent)2個方法為設置定時任務之處,本文方案要修改成相同心跳時段間隔就需要先取消該方法調用,然后修改成setWindow(interg-er,long,long,PendingIntent),該方法的第3個參數(shù)就是設置心跳間隔的時間長度,這里本文統(tǒng)一規(guī)定為300 000 ms,也就是5 min,這樣將使得不同App也有相同的心跳間隔。而此類里還有一個setRepeating(Inter-ger,Long,Long,PendingIntent)此方法在Android API19之前是精確執(zhí)行的,在其之后被設置為不精確執(zhí)行,這也是官方推薦做法,所以本節(jié)方案直接統(tǒng)一設置為非精確執(zhí)行方法setInexactRepeating()方法。

2)CPU喚醒類WakeLock

此類里主要是在息屏后,應用還想繼續(xù)執(zhí)行任務而喚醒CPU的實現(xiàn)類,但是通常對于一些存在心跳機制的新聞或者視頻網站應用的推送用戶不希望其在息屏后還繼續(xù)執(zhí)行,也常常不需要推送消息后立馬將屏幕點亮,這樣將使得手機電量消耗極快,因此本文方案將用戶指定的應用中的獲取喚醒的方法acquire()以及重載方法都將其取消,達到自定義應用息屏后不再繼續(xù)耗電的作用。

3)賬號同步方法類ContentResolver

賬號同步方法是Android系統(tǒng)提供給第三方應用統(tǒng)一同步的實現(xiàn)類,國內應用常常是通過心跳線程在App內實現(xiàn)自己的賬號信息同步,但為以防萬一,常常也接入該接口服務保證信息的實時性,通常此接口的實用性并不能體現(xiàn)出來。所以,該類里的setSyncAutomatically(Acc-ount,String,Boolean)自動同步方法,本文方案將第3個參數(shù)設置為false,也就是禁止自動同步,此外,3個重載方法requestSync()本應用也攔截這些方法的調用,這完全根據用戶的選擇設定,本應用只會修改用戶要求修改的應用,因此,能夠降低用戶使用率低的應用的功耗,節(jié)省相應的手機資源。

通過Xposed框架提供的修改接口,開發(fā)者可以便捷地修改用戶要求的應用列表,達到節(jié)省一定手機資源的作用,并且這種修改是可逆的,用戶如果想恢復到原生狀態(tài),只需將已經選中的選項取消就可以保證應用所有功能的完整性。

3.4 應用優(yōu)化方案后的性能測試與分析

由于本文的方案是基于純凈安卓系統(tǒng)應用層實現(xiàn)的并且目標系統(tǒng)也是純凈Android系統(tǒng),實驗設備為Nexus7,系統(tǒng)為Android原生4.4版本,對于其他以定制ROM實現(xiàn)心跳同步的(如小米MIUI5以及之后版本的對齊喚醒功能),本節(jié)無法抽離功能來控制變量一致性進行實驗對比;此外對于制定特定自適應協(xié)議方法,這種方法只適用于基于此種協(xié)議開發(fā)的App,利用協(xié)議算法來達到同步心跳的目的,如環(huán)信、融云等推送服務,可對使用自身服務的App進行心跳同步,而對于微信、QQ、陌陌、WhatsApp這些自研心跳維持服務則無法進行優(yōu)化,而本文的方法則可以實現(xiàn)。因此本節(jié)僅針對本文方案的優(yōu)化效果進行檢測,因為本文方法基于應用層實現(xiàn)并以App形式展示且可以優(yōu)化幾乎所有具有心跳服務的應用,具有極大便利和簡潔性,是實現(xiàn)安卓系統(tǒng)上心跳同步的一種新的實現(xiàn)思路。

3.4.1 心跳流量檢測與分析

本節(jié)實驗是將開發(fā)好后的軟件功能應用于QQ、微信、陌陌、WhatsApp等4個應用,測試環(huán)境與測試時間與前面檢測過程一致,檢測結果如表4所示。

表4 應用優(yōu)化方案后各應用心跳流量消耗

表4列出了在2 h時間內,采用優(yōu)化方案后的應用心跳流量消耗,本節(jié)將此數(shù)據與2.1節(jié)的數(shù)據進行對比,實驗結果如圖5所示,可以看出,應用了優(yōu)化方案的應用心跳流量消耗比未使用優(yōu)化方案時的流量消耗基本上都有所減小,這在一定程度上可以減小用戶流量的消費額度。

圖5 應用優(yōu)化方案前后心跳流量大小對比

3.4.2 CPU占用時長檢測

此處檢測仍使用CPU占用時長作為電量指標,實驗環(huán)境與檢測工具與2.2節(jié)一致,檢測時長同樣為2 h,結果對比數(shù)據圖表如圖6所示。圖6展示了應用優(yōu)化方案前后各應用心跳占用CPU時間對比,從中看出應用心跳線程的占用時間大部分得到了降低。通過計算,如果用戶對此4個應用均應用了本文的優(yōu)化方略后,從整體上降低38%的CPU占用時長,可大大降低相應的電能消耗,提高了手機的性能。

圖6 應用優(yōu)化方案前后CPU占時對比

4 結束語

本文研究當今主流即時通信應用心跳的傳輸機制,介紹各個應用心跳的檢查與鑒別過程,并在Android系統(tǒng)平臺上對它們進行相應的性能測試,統(tǒng)計和分析它們所產生的資源耗用數(shù)據,提出一種基于Xposed框架的的性能優(yōu)化方案,并最終以iHeart應用形式實現(xiàn)。實驗結果表明,該實現(xiàn)方案有效地降低了功耗并節(jié)約了流量,從整體上提高了Android系統(tǒng)的性能。下一步將利用Android系統(tǒng)內部應用機器學習算法個性化設置各個應用心跳活動,以實現(xiàn)更友好的用戶體驗。

[1] Statista Company.Mobile Users Worldwide[EB/OL].(2016-01-24).https://www.statista.com/topics/2478/mobile-social-networks.

[2] 張文茂,章 淼,畢 軍,等.互聯(lián)網即時消息(Instant Messaging,IM)的研究現(xiàn)狀與展望[J].小型微型計算機系統(tǒng),2007,28(7):1162-1168.

[3] 關 琳,楊維忠,張琳峰.即時消息——網絡融合中的亮點業(yè)務[J].移動通信,2008,32(14):37-41.

[4] 朱和平.即時通信研究綜述[J].現(xiàn)代計算機(專業(yè)版),2006(12):55-58.

[5] DUANZ,GOPALAN K,DONG Y.Push vs.Pull:Implications of Protocol Design on Controlling Unwanted Traffic[C]//Proceedings of Steps to Reducing Unwanted Traffic on the Internet on Steps to Reducing Unwanted Traffic on the Internet Workshop.Berkeley,USA:[s.n.],2005:25-30.

[6] SHIHH P.Technology-push and Communication-pull forces Driving Message-based Coordination Perfor-mance[J].Journal of Strategic Information Systems,2006,15(2):105-123.

[7] POHJAM.Server Push with Instant Messaging [C]//Proceedings of ACM Symposium on Applied Computing.New York,USA:ACM Press,2009:653-658.

[8] GOBRIELS,MACIOCCO C,TAI C,et al.A EEAOC:Energy Efficient Always-on-Connectivity Arch-itecture[C]//Proceedings of the 8th International IARIA Conference of Wireless and Mobile Communications.Venice,Italy:[s.n.],2012:110-117.

[9] JOHNSONT.A Heartbeat Mechanism and Its Application in Gigascope[C]//Proceedings of the 31st International Conference on Very Large Data Bases VLDB Endowment.Trondheim,Norway:[s.n.],2005:1079-1088.

[10] 張 雷,金 德.基于Push通道客戶端的智能心跳機制研究與優(yōu)化[J].工業(yè)控制計算機,2013,26(1):82-84.

[11] 陳立浩.基于B/S和C/S的即時通信系統(tǒng)[J].計算機工程,2009,35(15):270-271.

[12] 馬志強.基于Android平臺即時通信系統(tǒng)的設計與實現(xiàn)[D].北京: 北京交通大學,2009.

[13] Leskovec J,Horvitz E.Planetary-scale Views on an Instant-messaging Network[C]//Proceedings of International Conference on World Wide Web.Washington D.C.,USA:IEEE Press,2008:915-924.

[14] PIELOTM.Didn’t You See My Message?:Predicting Attentiveness to Mobile Instant Messages[C]//Proceedings of the 32nd Annual ACM Conference on Human Factors in Computing Systems.New York,USA:ACM Press,2014:3319-3328.

[15] LI Y,LI J.Analysis of OTT Service Influence on Mobile Communications Network[C]//Proceedings of International Conference on Artificial Intelligence and Industrial Engineering.Phuket,Thailand:[s.n.],2015.