分类： Android平台
2014-12-02 09:07:40
Android系统会在系统资源不足的时候回收系统资源。
使用bindService()绑定的Service是与宿主组件相关的，所有如果宿主组件没有被系统回收销毁，这个服务除非宿主主动解除绑定，直到这个服务没有宿主绑定，即才会被销毁，这种情况只需要关心与它绑定的组件的是否被销毁即可。而对于使用startService()开启的服务而言，服务一旦开启，将与宿主无关，所以除了宿主调用stopService()或者服务自己调用stopSelf()外，它很可能在系统资源不足的时候被回收。
服务被系统销毁后，如何继续服务，可以使用Service.onStartCommand()方法的返回值设定，这个方法必须返回一个整型，用于设定系统在销毁服务后如何处理，这些返回的整型被系统封装成了常量，一般常用的有：
l START_NOT_STICKY：在系统销毁服务后，不重新创建服务，除非有额外的Intent启动服务。
l START_STICKY：在系统销毁服务后，重新创建服务和调用onStartCommand()，但会依照一个空的Intent对象执行任务，就如仅开始服务，但不执行命令，等待服务的继续工作。
l START_REDELIVER_INTENT：在系统销毁服务后，重新创建和调用onStartCommand()方法，依据之前启动它的Intent对象开启服务，进行之前未执行完的任务，如下载文件。
使一个Service对象常驻后台运行，在任何时候都不被销毁，思路：
l 开机启动：Android系统开启的时候会发送一个action为android.intent.action.BOOT_COMPLETED的广播，只需要一个广播接受者来接受这个Action，然后在其中启动服务即可。
l 意外停止：对于意外停止的服务，可以在服务的onDestory()方法中重新启动服务，这样刚销毁又重新启动。
l 意外销毁：当Service被意外销毁的时候，会发布一个action为android.intent.action.PACKAGE_RESTARTED的广播，只需监听这个广播，在其中重新启动服务即可。
l 系统回收：系统在资源不足的情况下会回收资源，但是也是有一定的规则的，回收的资源必定是优先级低的资源，所以提高Service的优先级，也可以保证一定的常驻系统后台，服务的优先级可以在清单文件中，配置节点下的节点的时候增加android:priority属性，将其的数值设定的比较高，此处数值越高，优先级越高，上线为1000。
l 还有一种极端的情况，可以使服务一旦启动，将不会被销毁，那在配置服务的清单文件的时候，在节点中增加android:persistent属性，并将其设置为true。不推荐使用，因为如果系统中安装了大量常驻组件，将会影响系统的使用。
