最近在写项目的时候遇到了service的多个问题，下面跟大家分享一下，简单说一下。

再写音乐播放器时，音乐播放器写在服务中，虽然有时不把mediaplayer写在service中，有时也能实现后台播放，但是一旦android 系统内存吃紧，就会马上kill掉它，把它写在service里是非常必要的，因为有时候，即使你写到service中，也不能保证service服务永远不被杀掉，这里就需要优化一下service的内存分配问题了。

好了先来说一下，service与UI界面通信，就像是音乐播放器，一旦服务中的mediaplayer暂停了，这时候就需要界面显示暂停状态。

在这里有两个办法：

1.通过service中Ibinder与activity通信，但是为了能够得知service中的状态，这里需要在service中自定义回调接口，从而完成界面的动态更改。(这是在网上看到的一个类似的示例http://itindex.net/detail/45126-android-service-activity)

2.第二个则就是通过service+broadcastReceiver的形式，通过service向需要改变UI的activity发送广播，activity接收到广播，从而做出相应状态的改变。

这里值得注意的是这里的广播接收器一般写成activity的内部类，然后需要在androidManifest文件中声明，注册使用的是动态注册，最后在activity  onDestroy（)方法中注销就好了。



下面来讲一下service的重启问题。

有时候我们需要防止自己的应用程序被第三方应用程序（**管家之类的）杀死，一般情况下是，在服务被杀死之后，马上重启服务。

android规范中指出进驻有service的进程的优先级别很高，除非是本应用自己调用stopService结束服务，否则即使第三方应用杀死该进程，而后进程也会自己重启（服务也重启）

我们不需要知道服务什么时候被杀死，或是怎么手动重启，通过设置以下属性，可设置服务是否自动重启。




每次调用startService(Intent)的时候，都会调用该Service对象的onStartCommand(Intent,int,int)方法,这个方法return 一个int值,return 的值有四种:

 


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的值传入。

    x


START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。