安卓端即时通信应用的心跳机制研究及性能优化

,,, ,

(苏州大学 计算机科学与技术学院,江苏 苏州 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.