,,, ,

(蘇州大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,江蘇 蘇州 215006)

0 概述

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

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

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

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

1 即時(shí)通信應(yīng)用的心跳檢測(cè)

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

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

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

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

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

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

圖1 各即時(shí)通信應(yīng)用心跳周期

圖2 原始心跳流程

圖3 目標(biāo)心跳設(shè)計(jì)流程

2 心跳機(jī)制對(duì)手機(jī)性能的影響分析

2.1 流量耗用檢測(cè)

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

表2 各即時(shí)通信應(yīng)用流量消耗情況

2.2 電池電量檢測(cè)

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

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

表3 各應(yīng)用占用CPU時(shí)長 s

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

2.3 實(shí)驗(yàn)分析與總結(jié)

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

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

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

3.1 方案概述

針對(duì)心跳機(jī)制的優(yōu)化本文主要分為2個(gè)方面內(nèi)容:

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

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

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

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

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

3.2 Xposed框架及心跳接口說明

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

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

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

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

//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,因?yàn)镃ontentProvider是Android的四大組件之一,是大家常常用到的用于各個(gè)應(yīng)用程序之間共享數(shù)據(jù)的服務(wù)類,而ContentResolver就是操作ContentProvider中數(shù)據(jù)的具體操作方式。但是本文在此處涉及的是ContentResolver另外功能—本地賬戶同步。因此本文主要關(guān)注其2類方法,一種是setSyncAutomatically(Account,String,Boolean)該方法是設(shè)置賬戶是否自動(dòng)同步。另外一種是requestSync(),它有3種重載方法分別為requestSync(Account,Strin-g,Bundle)、requestSync(SyncRequest)、requestSync(A-ccount,String,Bundle,Long),它們的作用是主動(dòng)請(qǐng)求直接同步。

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

3.3 iHeart應(yīng)用的實(shí)現(xiàn)

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

1)應(yīng)用包名的鑒別

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

2)心跳相關(guān)方法的截獲

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

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

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

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

2)CPU喚醒類WakeLock

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

3)賬號(hào)同步方法類ContentResolver

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

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

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

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

3.4.1 心跳流量檢測(cè)與分析

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

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

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

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

3.4.2 CPU占用時(shí)長檢測(cè)

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

圖6 應(yīng)用優(yōu)化方案前后CPU占時(shí)對(duì)比

4 結(jié)束語

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

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

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

[3] 關(guān) 琳,楊維忠,張琳峰.即時(shí)消息——網(wǎng)絡(luò)融合中的亮點(diǎn)業(yè)務(wù)[J].移動(dòng)通信,2008,32(14):37-41.

[4] 朱和平.即時(shí)通信研究綜述[J].現(xiàn)代計(jì)算機(jī)(專業(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通道客戶端的智能心跳機(jī)制研究與優(yōu)化[J].工業(yè)控制計(jì)算機(jī),2013,26(1):82-84.

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

[12] 馬志強(qiáng).基于Android平臺(tái)即時(shí)通信系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京: 北京交通大學(xué),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.