Android 进程常驻(2)----细数利用android系统机制的保活手段

这是一个轻量级的库,配置几行代码,就可以实现在android上实现进程常驻,也就是在系统强杀下,以及360获取root权限下,clean master获取root权限下都无法杀死进程

支持系统2.3到6.0

支持大部分设备,包括三星,华为,oppo,nexus,魅族等等

可以简单对开机广播进行保护


github地址:

https://github.com/Marswin/MarsDaemon

原理分析:

Android 进程常驻(0)----MarsDaemon使用说明

Android 进程常驻(1)----开篇

Android 进程常驻(2)----细数利用android系统机制的保活手段

Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述

Android 进程常驻(4)----native保活5.0以上方案推演过程以及代码详述

Android 进程常驻(5)----开机广播的简单守护以及总结



正文:




年前就开篇了android进程常驻,但是一直琐事不断,也一直没有静下心来整理,只是把项目传到的github,有好多朋友会来问我其中实现原理,其实也是一点一点推演过来的。我的想法就是按照我当时的推演过程,按顺序写完这几篇博客,也算是对那一个月努力的一个交代。


上一篇讲了系统管理进程和强杀进程的过程原理,今天就开始想一下,在此基础上,如何实现保活,当然作为一个android开发,最先想到的肯定是在framework层有没有什么机制可以利用实现保活,当时整理了以下几点(是对照自己当时写的ppt整理的,有些细节已经忘记):


1、将Service设置为前台进程

2、在service的onstart方法里返回 STATR_STICK

3、添加Manifest文件属性值为android:persistent=“true”

4、覆写Service的onDestroy方法

5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件

6、服务互相绑定

7、设置闹钟,定时唤醒

8、账户同步,定时唤醒

9、native层保活






好的,然后我们一个一个的来说



1、将Service设置为前台进程。

本质是修改了Service所在进程的进程优先级,详情请参照 Android 进程常驻(1)----开篇。有了前台进程的优先级,在android系统清理内存的时候,他被杀死的优先级仅高于前台的activity,也就是正在和用户交互的页面,而且使用ddms杀进程他也可以自己启动起来。

但是,然,并,卵!

首先ddms杀进程和在系统设置的正在运行中杀进程本身就不具威胁,在系统设置的所有应用中选择强行停止,仍然可以强停掉,360,cm等软杀更是能轻而易举杀死他。而且他还有一个缺点,在api 17以上,设置了一个前台服务,他会以一个无法消除的notification的样式出现在用户的手机状态栏里,大大降低了用户体验。看源码




所以一般这么用







2、在service的onstart方法里返回 STATR_STICK

没多大用,放在常规应用里的service ok,但保活的话还是差些。。。这里不多说了直接看源码注释




其他几个返回值分别代表了

START_STICKY_COMPATIBILITY:START_STICKY的兼容版本,但不保证服务被kill后一定能重启。 

START_STICKY:系统就会重新创建这个服务并且调用onStartCommand()方法,但是它不会重新传递最后的Intent对象,这适用于不执行命令的媒体播放器(或类似的服务),它只是无限期的运行着并等待工作的到来。

START_NOT_STICKY:直到接受到新的Intent对象,才会被重新创建。这是最安全的,用来避免在不需要的时候运行你的服务。

START_REDELIVER_INTENT:系统就会重新创建了这个服务,并且用最后的Intent对象调。等待中的Intent对象会依次被发送。这适用于如下载文件。






3、添加Manifest文件属性值为android:persistent=“true”

如果你的应用能设置这个属性,可以全文跳过我这个系列所有文章。因为他真的可以杀不死,像系统的keyguard进程,media进程,且这些进程的adj都是负数,代表了前台activity黑屏了他们也不会死。但是这个属性需要系统shareuid,然后编译不过,因为需要系统签名,什么?你用系统签名?请忽略我全部

所以然并卵。





4、覆写Service的onDestroy方法

你会说这么low也行?为了把我知道的所有方式都列举出来,所以这里也说一下,在设置里面的正在运行,注意是正在运行里面,点击关闭,会走onDestroy回调方法,你在这里可以把自己启动起来。

但是仍然然并卵,设置里面的force close才是真正的劲敌,还有root了的360,cm这些boos才是我们要解决的对象。




5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件

这个有必要说一下,这个广播相信可能有的朋友不是很清楚,这是一个android解锁的广播事件。

注意:

1.这不是SCREEN_ON\SCREEN_OFF广播,,这不是SCREEN_ON\SCREEN_OFF广播,这不是SCREEN_ON\SCREEN_OFF广播。

2.这是一个可以静态注册的广播,这是一个可以静态注册的广播,这是一个可以静态注册的广播。


所以在manifest里面注册之后不需要任何前提,理论上用户每次开屏解锁都会触发我们的onReceive事件,在这里我们可以检查进程服务是否在,不在就拉起来。

但是,这个事件只有解锁才有,如果用户的没有设置锁屏,那么这个事件就是没有的,而且我们的目标是保证进程一直存活,而不是尽可能多的活起来。所以这个当作一个补充的手段也不错,另外所有那些可以静态注册的广播都可以这样搞,前提是你不怕用户看到你申请了好多权限,当然这个USER_PRESENT事件是不需要权限的。

以下是几个常见可以静态注册的广播,另外android7取消了wifi的静态广播注册,没有证实

android.intent.action.USER_PRESENT
android.net.conn.CONNECTIVITY_CHANGE
android.intent.action.MEDIA_MOUNTED
android.intent.action.MEDIA_UNMOUNTED
android.net.wifi.RSSI_CHANGED
android.net.wifi.STATE_CHANGE
android.net.wifi.WIFI_STATE_CHANGED




6、服务互相绑定

这个是android里面一个特性,跨进程bind一个service之后,如果被bind的service挂掉,bind他的service会把他拉起来。依然然并卵,具体为什么以后再说。



7、设置闹钟,定时唤醒

市面上了解到的大部分应用是用这种保活方式,使用系统闹钟定时发通知过来唤醒进程。

但是,

且先不说高频的唤醒和手机厂商对于wakelock的控制上造成的耗电问题。单单保活效果上就很难过关,force close直接杀掉,没有挣扎的机会,360、cm更是随便杀。说下alarm的几个参数


AlarmManager.RTC,硬件闹钟,不唤醒手机(也可能是其它设备)休眠;当手机休眠时不发射闹钟。

AlarmManager.RTC_WAKEUP,硬件闹钟,当闹钟发躰时唤醒手机休眠;

AlarmManager.ELAPSED_REALTIME,真实时间流逝闹钟,不唤醒手机休眠;当手机休眠时不发射闹钟。

AlarmManager.ELAPSED_REALTIME_WAKEUP,真实时间流逝闹钟,当闹钟发躰时唤醒手机休眠;

 

嗯,RTC闹钟和ELAPSED_REALTIME最大的差别就是前者可以通过修改手机时间触发闹钟事件,后者要通过真实时间的流逝,即使在休眠状态,时间也会被计算。






8、账户同步,定时唤醒

这个估计也是好多人不知道一点,android系统里有一个账户系统,设置一个自己的账户,android会定期唤醒账户更新服务,我们可以自己设定同步的事件间隔。且发起更新的是系统,不会受到任何限制。看下效果,晚上下班到第二天早晨,开着cm后台自动清理




 log上来看唤醒时间一直正常,且在睡眠中是不会产生唤醒的。

使用方法也很简单:









那么,这就是我们想要的?


还不行!!!


他的局限性在于:

第一,用户会在系统设置的账户列表里面看到一个不认识的账户;

第二,同步的事件间隔是有限制的,最短1分钟,见源码,如果小雨60秒,置为60秒。而且各种国产机怎么改的源码我们未可知,是不是都能用仍然未可知;

第三,很致命,某些手机比如note3需要手动设置账户,你如何骗你的用户给你手动设置账户完了之后不卸载你;

第四,也很致命,必须联网!google提供这个组件是让你同步账户信息,不联网你同步个鬼,我们要保活,可以不联网不做事,但是不能不联网就死


但是,把他放在最后,仍然是一个很好的保活补充手段

9、native层保活

终于要到正文了。下一篇开启native保活的篇章,首先上一个github上别人的native保活方案,也是绝大多数公司采用的native方案,笔者所在公司亦是北京知名互联网公司,之前也采取的类似方案,但是,其实只是开了一个native进程定期发intent而已,缺陷是:只能简单保活,360、cm碾压其无压力,但仍有可借鉴之处,下一篇分析,然后开始我的native之旅

https://github.com/Coolerfall/Android-AppDaemon



相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页