Android 系统对于内存管理,为了使系统有序稳定的运行,系统内部会自动分配,控制程序的内存使用。当系统觉得内存的资源非常有限的时候,为了保证一些优先级高的程序能运行,就会杀掉一些他认为不重要的程序或者服务来释放内存, 比如项目需求需要Service在后台实时监听网络连接状态,或者其他用Service执行的后台操作,为了保证Service一直运行不被系统释放掉,就需要用到Service保活技术。
好多博客上写的单一的保活手段可能在实际代码的检测上发现并不好用,下面我记录的Service保活,使用了3重的保险,Service保活的3重实现。 在我所经历的实际的项目中,MessageService这个服务在后台监听网络,wifi,屏幕亮度等等的状态,为了保证这个Service不被杀死能一直监听,用到了Service的保活,保证Service即使被杀死也能立刻再重新调用起来
第一重:
startForeground前台服务的方式启动Service,并在onStartCommand回调中设置START_STICKY,这样当服务被kill那么START_STICKY会重新启动该Service ,这是一重处理,为了保证它不被杀掉,只做一重是不够的,所以还要写其他几重的保活
第二重:
在MessageService里开一个Service当做MessageService的守护服务。当这两个服务任意一个销毁的时候,都会发送相同的广播,由项目中的ServiceReceiver这个广播接收器来监听,如果收到了任意一个Service销毁时候发出的广播,就打开这两个Service ,启动的id保持一致,这样当使用的ID一致时,仅仅只会更新当前service的Notification。这个处理跟两个Service的互拉有一些区别,
第三重:
将守护的service在adminfest中添加android:process=":guard"
public class MessageService extends Service {
public final static ConnectReceiver conncetReceiver = new ConnectRec