对于移动APP来说,IM功能正变得越来越重要,它能够创建起人与人之间的连接。社交类产品中,用户与用户之间的沟通可以产生出更好的用户粘性。
在复杂的 Android 生态环境下,多种因素都会造成消息推送不能及时达到客户端。另外,不稳定的移动网络也给数据传输的速率和可靠性增加了障碍。
本文详解了网易云信IM SDK在应对弱网环境、移动端硬件限制以及Android复杂的生态现状时的探索与心得.如何实现不影响用户体验的后台保活,改善的长连接加推送组合方案,以及在弱网环境大数据传输的优化实践。
带着思考阅读:
1.什么是IM
2. IM SDK如何实现不影响用户体验的后台保活
3.如何做长连接加推送组合方案
4.如何在弱网环境下优化大数据传输
IM的定义
IM由两个字组成:Instant,Messaging。
即时性要求有新消息时能够立即收到,如果程序在后台,则要能立即收到推送通知。
通信则要求稳定可靠,系统不宕机,程序不崩溃,安全,传递消息时不会被拦截监听,消息不丢,顺序不乱,不重复,如果包含音视频聊天,则要求延迟低,流畅不卡顿。
要真正做出一套稳定可靠的商用级IM系统,挑战非常大。
第一个问题是消息推送。iOS有 APNS做推送,相当稳定。Android本身也有GCM可以用,但是在国内有“墙”,直接就把GCM等等google的服务全部挡在外面。为了实现即时稳定的消息推送,从易信时代开始,网易就开始研究,随着时间的推移,困难和方法也在不停的变化。
对于IM,当APP退到后台,是必须还能够收到新消息提醒的,没有GCM,怎么办?在最初,唯一能做的,就是后台运行了。这几乎是接收推送的唯一途径,就算是到现在,也是最主要的途径。Android从设计上,就是支持真后台运行的,后台运行的特性也是Android现在能如此成功的原因之一,但另一面,Android长久以来一直摆脱不了的卡顿,耗电等坏名声,后台运行也拖不了干系。因此,系统对于后台运行也不会放任自流。
APP在后台运行所面对的四大障碍
第一个障碍是Android的Low Memory Killer机制。手机的内存有限,当后台运行的进程越来越多,内存剩余量也就随之减少。当有一个新的APP想要启动,如果内存不够,LMK机制就会启动,从正在运行的进程中挑选一个清理掉,释放出空间,然后新的APP就可以运行了。
LMK有两个尺度去评判。一个是进程优先级,优先级越低,被清理的可能性越大,另一个是内存占用,占的内存越多,被清理的权重自然也越大。
因为LMK机制的存在,虽然APP允许在后台运行,但同样也面临随时被清理的风险。因此,网易需要在被清理后及时的重新启动。
第二个障碍是alarm,闹钟,有循环闹钟和一次性闹钟两种,在闹钟触发后启动对应的组件。
第三个障碍是在Manifest文件中静态注册的Receiver,通过监听各种系统事件,比如开机,网络变化,mount/unmounts等,在这些事件发生时启动组件,因为这种方式会造成在这些事件发生时系统容易卡顿,在7.0里面,Android增加了限制。
第四个障碍是JobScheduler,这是在5.0里面新增的,允许APP在特定事件发生时做一些动作,比如充电,切换到wifi等。
虽说无论怎么做,APP终究免不了一死,但通过对照LMK的评判准则,还是可以降低APP被清理的概率的。第一个就是降低进程的内存占用。如果采用单进程的模式,由于进程中包含了UI,Webview,各种图片缓存等内容,内存必然会居高不下,降不下来。IM软件一般都会采用双进程甚至多进程的策略,将push进程独立出来,在push进程里只处理网络连接和push业务,不参与任何其他业务逻辑,更不包含任何UI。
以下是网易云信Android SDK的架构,按照分层的结构模式设计。最底下青色的一层是push层,他就是作为一个独立进程运行的。他只负责处理网络长连接的相关工作,比如安全加密,心跳,鉴权,封包解包等工作,所有业务逻辑都交给UI进程的服务模块去做。来看一下云信demo的进程内存占用情况。上面一个是主进程,看第四列PSS的数据,内存占用是50M左右,下面一个是push进程,内存占用只有10M左右。当处于后台时,push进程被清理概率比UI主进程低很多。
(网易云信SDK架构)
降低被清理概率的第二个手段是提升进程优先级。先看这个例子,这是绿色守护的一个截图,最上面是“暂不自动休眠”,因为这里列出的两个APP的状态都是工作中,对应的进程优先级是“可视进程”。但这两个APP并没有提供桌面小部门在运行,也没有指示前台服务的常驻通知栏提醒,事实上,他们就只是在后台运而已。通常进程退到后台后,其进程优先级类型就变成了较低的后台进程,而不是这样的“可视进程”,他们是通过什么方法来提升优先级,降低被清理概率呢?
(绿色守护截图)
Android在设计前台服务上有一个漏洞,通过两个服务配合就能创建一个隐形的前台服务。这里有两个已经启动的service: A和B。先在A中调用startForeground,提供一个NOTIFY_ID, 然后A就变成前台服务了,同时有了一个ID为NOTIFY_ID的常驻通知栏提醒,然后网易在B中也调用startForeground,提供相同的NOTIFY_ID, B也变成了前台服务,因为两个通知ID相同,因此这一次就不会创建新的通知栏提醒了。然后再在A中调用stopForeground,A的前台属性被取消,同时,常驻通知栏提醒也会被移除,但是,service B并不会受到任何影响,还是前台服务,这是再把A停掉,进程就只剩下前台服务B了,进程也变成了前台进程,但用户不会有任何感知。
正常来说,做了上面3步之后,进程就能够比较稳定的在后台运行了。
但在有些情况下,推送进程却永远起不来。跟踪之后发现,除了系统能够杀掉后台运行的进程外,用户也一样是可以杀死进程的。用户杀掉进程的方式有两种,一种是在最近任务列表中将app划掉,这种方式和系统杀掉进程效果相同。另外一种就是通过这里的force stop,这种方式比系统清理更加彻底。不但app正在运行的进程会被清理,app当前在重启列表中的待重启服务,注册的各种闹钟,事件监听组件等都会被移除,除非用户在主动点击或者系统重启等外力,app没法再自己重新爬起来了。
在有些国内的像MIUI一类的ROM上,用户从最近任务列表中将app移除,效果竟然也是force stop。正常来说,如果是用户主动操作,app本身也不应该再重启了。但有些时候这个并不是用户本意,况且,对于IM软件来说,消息推送是一定要得到保障的,否则不明正确的吃瓜群众们会觉得是软件不行,连消息推送都做不好。
APP安卓进程保活的好办法
第一个是通过两次fork加上exec的方式。两个fork后,第一次fork的进程退出,第二次fork出来的进程就会被init进程领养。用户此时再force stop,因为这个进程复进程是init,而不是Zygote,因此不会被清理。由于这个进程还是从android进程fork出来的,带有android运行时环境以及复进程的资源,所以内存会比较大,这里可以再通过exec命令,打开一个纯linux的可执行文件,开启一个daemon进程,其内存占用大概只有100K+,对用户也就完全无感了。利用这个后台进程,可以定时的将push进程拉起来。此种方式只在5.0以下的系统中有效,在4.4及以上系统中,SELinux特性是强制开启的,exec没有权限执行,同时在5.0之后,ActivityManager在做force stop以及移除任务时,只要是具有相同的uid的进程,就会全部清理掉,不再漏掉没有虚拟机环境的进程。
最后一个后台保活的手段是一个大杀器。因为前面所列的所有保活手段都不是那么保险,因此想出来这么一个互相保活的方式。当一个APP进程起来后,他就去扫描已安装的应用列表,看看有没有自己的兄弟姐妹,比如说同一个长的APP,或者是集成了同一个SDK的APP,如果有,就把这些APP都拉起来。这也就是现在比较出名的“全家桶”方案。虽说这种方法确实能够带来较高的后台存活率,特别是那些大厂和应用广泛的sdk,但是这种方式对于用户的伤害也非常大,如果有后台推送的必要性,且不会对用户体验造成太大伤害时,此方式还可以使用,但如果只是为了推广告,则会对用户造成伤害,反过来,也可能会导致用户直接卸载APP。
现在各种手机管理软件都会对这种全家桶唤醒方式做限制,特别是在root过的机器上,可以做到完全切断这些唤醒路径。同时,很多ROM也会自带管理软件,限制后台运行和后台唤醒,以便给设备换取更长的续航。在目前国内的Android生态环境中,无论采用什么方式,想要一直在后台运行时越来越难了,需要重新想另外的办法来保障消息推送。另一方面,作为开发者,也有义务为用户提供更好体验的软件,而不是无休止的在后台浪费用户的资源。
转载于:https://my.oschina.net/u/2550800/blog/1837204