Android SERVICE后台服务进程的守护

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

在早些时候，我们可以通过在


1. service中重写onStartCommand方法，这个方法有三个返回值， START_STICKY是service被kill掉后自动

public int onStartCommand(Intent intent, int flags, int startId) {       

   return START_STICKY;   

}

2. 配置android:persistent="true" 


3. setForeground(true); 


4. android:process=”com.xxx.xxxservice”配置到单独的进程中

以上的方法要么只是提升service优先级或者存活率, 并不能解决被安全软件强行杀死的问题.

要么像第四种单独的进程运行service在360老的版本是可以的,但是在360的比较新的版本中仍然会被杀死.

如何保持Service的运行状态是现在要说明的，核心就是利用ANDROID的系统广播，触发自己的程序检查Service的运行状态，如果被杀掉，就再起来。


常用的有开机广播，解锁屏幕的广播，电量变化等等， 其中解屏的广播算比较频繁的了，但是也并不能保证一定的频率，尤其是在特定的时间里(比如用户睡觉的时候，用户并不进行解锁操作).而我们仍要做一些操作的时候，就没有办法了.

因此，我采用了一种别的方案. 另外再加上两个类似一守护进程的Service， 分别检查Service的运行状态，注册响应的广播，对其进行守护,一旦发现没有运行就将其启动.

我利用的系统广播是


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


它的优点就是间隔时间短而且非常稳定, 而其他的广播并不能保证这一点,当然，在具体的应用中还是要根据需求使用, 结合其他广播来保证自己的service一定会被重启.

毕竟现在安全软件是越来越厉害了，更新得也是非常频繁. 有时间还是要看下还有没有其他的方法，综合几种来使用.

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


1、 Intent.ACTION_TIME_TICK的使用


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


registerReceiver()方法注册。


在ThisApp extends Application 或者在service里注册广播：
  

[java] view plaincopy

1. IntentFilter filter = newIntentFilter(Intent.ACTION_TIME_TICK);   
2.       
3.     MyBroadcastReceiver receiver = new MyBroadcastReceiver();   
4.     registerReceiver(receiver, filter);   

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

[java] view plaincopy

1.  boolean isServiceRunning = false;   
2.   
3.   
4.     if (intent.getAction().equals(Intent.ACTION_TIME_TICK)) {   
5.         
6.     //检查Service状态   
7.         
8.     ActivityManager manager = (ActivityManager)AppApplication.getContext().getSystemService(Context.ACTIVITY_SERVICE);   
9.     for (RunningServiceInfo service :manager.getRunningServices(Integer.MAX_VALUE)) {   
10.     if("so.xxxx.xxxxService".equals(service.service.getClassName()))   
11.             
12.      {   
13.      isServiceRunning = true;   
14.     }   
15.         
16.      }   
17.     if (!isServiceRunning) {   
18.     Intent i = new Intent(context, xxxService.class);   
19.            context.startService(i);   
20.     }   
21.   
22.   
23. }   

终极解决方案: 使用Kni,在 c端 fork进程，检测Service是否存活，若Service已被杀死，则进行重启Service.   至于检测方式，可以轮询获取子进程Pid,若为1, 则说明子进程被Init进程所领养,已经成为了孤儿进程.    但是这种方式比较消耗电量，并且由于不同手机系统定制的改变，当应用被强制停止时，父进程并不一定被真正杀死，因此在一些特定机型上是无法通过此方式进行判断. 这里推荐使用liunx socket的方式进行类似心跳包的检测，并且当触发检测Service是否被杀死之前，需要判断应用是否已经被卸载，如果应用已经被卸载，则不再进行检测Service行为，直接调用exit(0)退出子进程，避免浪费系统资源和消耗电量.

如有转载，请声明出处: 时之沙: http://blog.csdn.net/t12x3456

StartCommond几个常量参数简介：

1、START_STICKY

在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建     service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent。

2、START_NOT_STICKY

在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。

3、START_REDELIVER_INTENT

在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。

[java] view plaincopy

1. @Override  
2. public int onStartCommand(Intent intent, int flags, int startId) {  
3.     flags = START_STICKY;  
4.     return super.onStartCommand(intent, flags, startId);  
5. }  

【结论】 手动返回START_STICKY，亲测当service因内存不足被kill，当内存又有的时候，service又被重新创建，比较不错，但是不能保证任何情况下都被重建，比如进程被干掉了....

现在研究NDK中，