Android SERVICE后台服务进程的自启动和保持

Service组件在android开发中经常遇到，其经常作为后台服务，需要始终保持运行，负责处理一些必要（见不得人）的任务。而一些安全软件，如360等，会有结束进程的功能，如果不做Service的保持，就会被其杀掉。

如何保持Service的运行状态是现在要说明的，核心就是利用ANDROID的系统广播，这一不会被其他软件影响的常驻程序触发自己的程序检查Service的运行状态，如果被杀掉，就再起来。

我利用的系统广播是Intent.ACTION_TIME_TICK，这个广播每分钟发送一次，我们可以每分钟检查一次Service的运行状态，如果已经被结束了，就重新启动Service。

下边就是具体的代码和注意事项了：

1、 Intent.ACTION_TIME_TICK的使用

我们知道广播的注册有静态注册和动态注册，但此系统广播只能通过动态注册的方式使用。即你不能通过在manifest.xml里注册的方式接收到这个广播，只能在代码里通过registerReceiver()方法注册。

在ThisApp extends Application 里注册广播：

IntentFilter filter = newIntentFilter(Intent.ACTION_TIME_TICK); 
MyBroadcastReceiver receiver = new MyBroadcastReceiver(); 
registerReceiver(receiver, filter); 

在广播接收器MyBroadcastReceiver extends BroadcastReceiver的onReceive里

if (intent.getAction().equals(Intent.ACTION_TIME_TICK)) { 
  
//检查Service状态 
  
} 

2、Service的检查与启动

boolean isServiceRunning = false; 
ActivityManager manager = (ActivityManager)ThisApp.getContext().getSystemService(Context.ACTIVITY_SERVICE); 
for (RunningServiceInfo service :manager.getRunningServices(Integer.MAX_VALUE)) { 
if("so.xxxx.WidgetUpdateService".equals(service.service.getClassName())) 
       //Service的类名 
{ 
isServiceRunning = true; 
} 
  
 } 
if (!isServiceRunning) { 
Intent i = new Intent(context, WidgetUpdateService.class); 
       context.startService(i); 
} 

另一个话题，Service的开机启动。

实现和上边的类似，也是通过监控开机的系统广播来启动Service。但其实你做了上边的检查也就不会做开机启动了，因为过一两分钟就会通过上边的程序启动Service了。代码如下：

1. if (intent.getAction().equals(Intent.ACTION_BOOT_COMPLETED)) { 
2. Intent i = new Intent(context, LogService.class); 
3.     context.startService(i); 
4.     }

Android中保持Service的存活
 
如何让Service keep alive是一个很常见的问题。
 
在APP开发过程中，需要Service持续提供服务的应用场景太多了，比如闹钟需要作出及时提醒，那么比如得有一个Service不断去比较当前时间和设置时间；QQ要能流畅的聊天，必然也需要及时接收消息等。
 
但是Android并没有保证Service有这样功能，毕竟一个系统面对的是用户，必然以对用户友好为先。
 
关于如何让Service keep alive，我在上篇博客给出的解决方案是：方案一，让服务器端发一个推送，检查Service是否还存活；方案二，将Service独立出来，运行在另一个进程中。
 
这两个方案有些地方需要说明和改进，然后还会有其他方案补充进来。
 
 
 
方案一：利用推送来确保Service存活。
方案一的做法有点“偷懒”。因为相当于把这个难题转移给推送服务提供者来处理，或者说，只需要依靠推送，就不需要自己去考虑存活问题。
 
推送一直是移动客户端开发的热门话题（实际上也是传统软件开发的热门话题）。
 
一般情况下，C/S结构（B/S是特殊的C/S结构）中的业务流程是这样的：客户端主动向服务器端发出请求，服务器端响应请求，建立二者之间的连接。通过建立的链接，双方可以发送/接收数据。最后客户端和服务器端断开连接。也就是说，客户端是主动方，是请求连接的发起者；服务器端保持对某个端口的监听（0-1023是系统端口号，比如80端口被指派给HTTP），而被动地等待客户端的连接请求。
 
那么推送指的是，服务器端在没有收到请求的情况下主动向客户端发送信息，比如服务器端收到一封邮件后主动发往邮件的客户端。
 
推送是如何实现的呢？首先，服务器端的功能还是不变，监听某个端口等待请求。然后我们可以看到，服务器端能主动发送信息的唯一时间段就是在建立了服务器端到客户端的连接之后、二者断开连接之前。因此，推送的实现就是基于保持服务器端和客户端的连接一直存在，方式可以是持续连接或者轮询。
 
回到Service这个问题上来，推送服务的提供者必然会保证推送技术的稳定性，依靠推送，可以唤醒我们的APP，那么保证Service的存活也就不在话下。
 
方案二：将Service运行在另一个进程中。
将Service放在另一个进程中，可以避免APP所在的进程因资源紧张或者被用户手动结束的时候，Service也被结束。
 
这个做法的另一个优点是，可以让Service独立出来，为同一个公司的不同APP提供相同的服务。比如当大部分APP都需要同一个信息的时候，为每个APP都写一个Service显然不好，这时完全可以写一个独立进程中的Service，为所有APP提供信息。
 
当然，这个方案有个缺点是，当某些手机助手无脑式结束掉全部的非系统进程时，Service无法存活。
 
方案三：让onStartCommand（）函数的返回值为START_STICKY，同时在onDestroy（）中重启Service
当返回值为该值时，Service被kill之后会被系统自动重启。
 
同时，在Service的onDestroy（）中重启Service，可以给Service的重启做双重保证。
 
但是显然的缺点是，当APP的进程被kill后，这个方案就会失效。
 
方案四：使用“守护Service”。
即除了你需要存活的Service外，专门写一个Service，并使该Service运行在另一个进程中。
 
当两个Service中有一个Service被kill，就在另一个Service中去重启该Service。
 
从手机中进程的数量上判断，搜狐视频、触宝号码助手等使用的正是该方式。
 
方案五：将Service所在的APP提升至系统应用级别
在配置文件中的Application节点做这样的设置：android:persistent=”true”可以将APP提升至系统级别。
 
相信不管什么手机助手都不会去kill这一块的APP。
 
从手机中QQ被手动kill后系统出现的对话框判断，手机QQ正是使用的这一方案。
 
方案六：接收系统的广播
可以用BroadCastReceiver去接收系统的广播，比如时间变化的广播、电量变化的广播等。
 
这样基本上Service就无法被kill了。
 
总结：
能保证Service完全不会被杀死的方案是方案一和方案六。
 
比较轻量的方案是方案二和方案三。
 
我个人认为比较好的方案是方案四和方案五——那些大厂选择这样的方案是有道理的。具体使用哪个得看自己的需求。
 
虽然标题是说保持Service持续存活，但是并不是说一定要在任何情况下存活。十分不建议使用方案一和方案六。因为当用户发现，不管他怎么操作都无法停止一个APP时，带给他的只有恐慌，那么小手一抖的情况下，APP就只能被删除了。