android service被系统回收的解决方法

android service被系统回收的解决方法

博客分类：

•  

• Android开发

androidservicekill 

本身的app的service老是容易被系统回收，搜罗了一下，基本上的解决思路有如下几种： 
1.把service写成系统服务，将不会被回收（未实践）： 
在Manifest.xml文件中设置persistent属性为true，则可以使该服务免受out-of-memory killer的影响。可是这种作法必定要谨慎，系统服务太多将严重影响系统的总体运行效率。 
2.提升service的优先级（未实践）： 
设置android:priority="1000" 

Xml代码  

1. <!-- 为了消去加上android:priority="1000"后出现的警告信息，能够设置android:exported属性，指示该服务是否可以被其余应用程序组件调用或跟它交互 -->  

2.         <service android:name="com.example.helloandroid.weatherforecast.service.UpdateWidgetService" android:exported="false" >  

3.             <!-- 为防止Service被系统回收，能够经过提升优先级解决，1000是最高优先级，数字越小，优先级越低 -->  

4.             <intent-filter android:priority="1000"></intent-filter>  

5.         </service>  

3.将服务写成前台服务foreground service（已实践，很大程度上能解决问题，但不能保证必定不会被杀）： 
重写onStartCommand方法，使用StartForeground(int,Notification)方法来启动service。 
注：前台服务会在状态栏显示一个通知，最典型的应用就是音乐播放器，只要在播放状态下，就算休眠也不会被杀，若是不想显示通知，只要把参数里的int设为0便可。 

Java代码  

1. Notification notification = new Notification(R.drawable.logo,  

2.                 "wf update service is running",  

3.                 System.currentTimeMillis());  

4.         pintent=PendingIntent.getService(this, 0, intent, 0);  

5.         notification.setLatestEventInfo(this, "WF Update Service",  

6.                 "wf update service is running！", pintent);  

7.           

8.         //让该service前台运行，避免手机休眠时系统自动杀掉该服务  

9.         //若是 id 为 0 ，那么状态栏的 notification 将不会显示。  

10.         startForeground(startId, notification);  

同时，对于经过startForeground启动的service，onDestory方法中须要经过stopForeground(true)来取消前台运行状态。 

ps：若是service被杀后下次重启出错，多是此时重发的Intent为null的缘故，能够经过修改onStartCommand方法的返回值来解决： 
START_STICKY：若是service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试从新建立service，因为服务状态为开始状态，因此建立服务后必定会调用onStartCommand(Intent,int,int)方法。若是在此期间没有任何启动命令被传递到service，那么参数Intent将为null。 
START_NOT_STICKY：“非粘性的”。使用这个返回值时，若是在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。 
START_REDELIVER_INTENT：重传Intent。使用这个返回值时，若是在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。 
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后必定能重启。 

Java代码  

1. //if this service's process is killed, then it will be scheduled for a restart and the last delivered Intent re-delivered to it again   

2. return Service.START_REDELIVER_INTENT;  

4.利用ANDROID的系统广播检查Service的运行状态，若是被杀掉，就再起来（未实践）： 
利用的系统广播是Intent.ACTION_TIME_TICK，这个广播每分钟发送一次，咱们能够每分钟检查一次Service的运行状态，若是已经被结束了，就从新启动Service。 
具体的实现，能够参考这个连接：http://mobile.51cto.com/abased-374969.htm 

补充：以上是解决service容易被回收的方法，可是再进一步深究，为何service会被系统杀掉呢？经过分析手机的logcat日志发现这么一段话： 

引用

06-19 08:01:32.755 W/ActivityManager( 2081): Killing ProcessRecord{43a96570 6437:com.example.helloandroid/u0a187}: background ANR 
06-19 08:01:32.910 I/ActivityManager( 2081): Process com.example.helloandroid (pid 6437) (adj 0) has died. 

看来这个ANR（Application Not Responding）是关键。上网查到的解释是： 在以下状况下，Android会报出ANR错误： – 主线程 (“事件处理线程” / “UI线程”) 在5秒内没有响应输入事件 – BroadcastReceiver 没有在10秒内完成返回 一般状况下，下面这些作法会致使ANR 一、在主线程内进行网络操做 二、在主线程内进行一些缓慢的磁盘操做（例如执行没有优化过的SQL查询） 主线程中执行过多的操做也是很差的，个人主线程里有访问网络的处理，因而想办法将网络访问移出主线程，一般有两种方法：把访问网络放在独立线程或者异步线程AsyncTask中。至于具体怎么实现，google之。