安卓端即時通信應用的心跳機制研究及性能優化

,,, ,

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

0 概述

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

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

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

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

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

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

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

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

表1 QQ數據包交互信息

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

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

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

圖2 原始心跳流程

圖3 目標心跳設計流程

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

2.1 流量耗用檢測

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

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

2.2 電池電量檢測

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

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

表3 各應用占用CPU時長 s

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

2.3 實驗分析與總結

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

3 基于Xposed框架的性能優化方案

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

3.1 方案概述

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

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

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

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

圖4 本文方案實現流程

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

3.2 Xposed框架及心跳接口說明

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

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

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

2)android.os.PowerManager.WakeLoc該類是系統提供給應用開發者獲取運行鎖的服務類,在用戶設備息屏后,設備將進入休眠狀態,應用要想運行必須要先獲得運行鎖,才能喚醒CPU進行相應的操作,這也就導致用戶即使將App退出到后臺,App還是可以通過喚醒鎖申請資源繼續工作。官方給出了獲得喚醒鎖的一致方法,如代碼所示。從中可以知道整個喚醒鎖的獲得先通過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的四大組件之一,是大家常常用到的用于各個應用程序之間共享數據的服務類,而ContentResolver就是操作ContentProvider中數據的具體操作方式。但是本文在此處涉及的是ContentResolver另外功能—本地賬戶同步。因此本文主要關注其2類方法,一種是setSyncAutomatically(Account,String,Boolean)該方法是設置賬戶是否自動同步。另外一種是requestSync(),它有3種重載方法分別為requestSync(Account,Strin-g,Bundle)、requestSync(SyncRequest)、requestSync(A-ccount,String,Bundle,Long),它們的作用是主動請求直接同步。

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

3.3 iHeart應用的實現

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

1)應用包名的鑒別

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

2)心跳相關方法的截獲

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

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

1)心跳觸發類AlarmManager

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

2)CPU喚醒類WakeLock

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

3)賬號同步方法類ContentResolver

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

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

3.4 應用優化方案后的性能測試與分析

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

3.4.1 心跳流量檢測與分析

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

表4 應用優化方案后各應用心跳流量消耗

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

圖5 應用優化方案前后心跳流量大小對比

3.4.2 CPU占用時長檢測

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

圖6 應用優化方案前后CPU占時對比

4 結束語

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

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

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

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

[4] 朱和平.即時通信研究綜述[J].現代計算機(專業版),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].工業控制計算機,2013,26(1):82-84.

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

[12] 馬志強.基于Android平臺即時通信系統的設計與實現[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.