Android之Service详解（一）

一、Service简述

Service是Android四大组件之一，通常称之为“后台服务”，其中“后台”一词是相对于前台而言的，具体是指其本身的运行并不依赖于用户可视的UI界面，使用Service可以在后台执行长时间的操作，Service并不与用户产生UI交互。其他的应用组件可以启动Service，即便用户切换了其他应用，启动的Service仍可在后台运行。

一个组件可以与Service绑定并与之交互，甚至是跨进程通信（IPC）。例如，一个Service可以在后台执行网络请求、播放音乐、执行文件读写操作或者与 content provider交互 等。

二、定义一个Service

首先看一下如何在项目中定义一个Service:取名为MyService，并让它继承Service，代码如下：

public class MyService extends Service {    public MyService() {    }    @Override    public IBinder onBind(Intent intent) {        return null;    }}

onBind方法时Service中唯一的抽象方法，所以必须要在子类中实现。

既然定义了一个服务，那就应该在Service中去处理一些事情，这时需要重写Service中的另外一些方法：

public class MyService extends Service {    public MyService() {    }    @Override    public IBinder onBind(Intent intent) {        return null;    }    @Override    public void onCreate() {        super.onCreate();    }    @Override    public int onStartCommand(Intent intent, int flags, int startId) {        return super.onStartCommand(intent, flags, startId);    }    @Override    public void onDestroy() {        super.onDestroy();    }}

可以看到，又重写了onCreate()，onStartCommand()，onDestroy()三个方法。

onCreate()：当Service第一次创建时，回调该方法。该方法只被回调一次，并在onStartCommand() 或 onBind()方法被回调之前执行。若Service处于运行状态，该方法不会回调。

onStartCommand()：当其他组件调用startService()方法请求启动Service时，该方法被回调。一旦Service启动，它会在后台独立运行。当Service执行完以后，需调用stopSelf() 或 stopService()方法停止Service。（若您只希望bind Service，则无需调用这些方法）

onBind()：当其他组件调用bindService()方法请求绑定Service时，该方法被回调。该方法返回一个IBinder接口，该接口是Service与绑定的组件进行交互的桥梁。若Service未绑定其他组件，该方法应返回null。

onDestroy()：当Service被销毁时回调，在该方法中应清除一些占用的资源，如停止线程、接触绑定注册的监听器或broadcast receiver 等。该方法是Service中的最后一个回调。

如果某个组件通过调用startService()启动了Service（系统会回调onStartCommand()方法），那么直到在Service中手动调用stopSelf()方法、或在其他组件中手动调用stopService()方法，该Service才会停止。

如果某个组件通过调用bindService()绑定了Service（系统不会回调onStartCommand()方法），只要该组件与Service处于绑定状态，Service就会一直运行，当Service不再与组件绑定时，该Service将被destroy。

当系统内存低时，系统将强制停止Service的运行；若Service绑定了正在与用户交互的activity，那么该Service将不大可能被系统kill（。如果创建的是前台Service，那么该Service几乎不会被kill。否则，当创建了一个长时间在后台运行的Service后，系统会降低该Service在后台任务栈中的级别——这意味着它容易被kill，所以在开发Service时，需要使Service变得容易被restart，因为一旦Service被kill，再restart它需要其资源可用时才行。

另外，每个服务在AndroidManifest.xml文件里进行注册才能生效：

<manifest ... >  ...  <application ... >      <service android:name=".MyService" />      ...  </application></manifest>

除此之外，在<service>标签中还可以配置其他属性，比如，需要启动该service所需的权限、该service应运行在哪个进程中 等。android:name属性是唯一不可缺省的，它指定了Service的全限定类名。一旦发布了应用，该类名将不可更改。

为了保证应用的安全，请使用显式Intent启动或绑定一个Service，请不要在<service>标签中配置intent-filter。若不确定该启动哪个Service，那么可以在<service>中配置intent-filter，并在Intent中排除该Service，但必须调用Intent的setPackage()方法，来为启动的service消除歧义。（setPackage()方法传入一个String参数，代表一个包名。该方法表示该Intent对象只能在传入的这个包名下寻找符合条件的组件，若传入null，则表示可以在任意包下寻找。）

将android:exported属性设为false，表示不允许其他应用程序启动本应用的组件，即便是显式Intent也不行。这可以防止其他应用程序启动你的service组件。

三、启动和停止服务

1、启动Service

若需要启动Service，见下面所示：

Intent intent = new Intent(this, HelloService.class);startService(intent);

其他组件调用startService()方法可以启动一个Service，接着，Service会回调onStartCommand()生命周期方法，若该Service未处于运行状态，系统将首先回调onCreate()，接着再回调onStartCommand()。若您希望Service可以返回结果，那么需要通过调用getBroadcast 返回的PendingIntent启动Service（将PendingIntent包装为Intent），service可使用broadcast 传递结果。

startService()方法中传入一个Intent参数，用于显式指定目标Service的名字，并携带data以供Service使用，该Intent参数将回传至onStartCommand()方法中。

比如说，Activity需要向在线数据库中上传数据，那么可以调用startService()启动一个Service，并将数据传入Intent的data中，接着，onStartCommand()方法会接收这个Intent并开启一个线程将数据上传至网络，当数据上传完成后，该Service将停止并被destroy。

注：多个启动Service的请求可能导致onStartCommand()多次调用。

2、停止服务

一个启动的Service必须管理自己的生命周期。系统不会主动stop或destroy一个运行的Service，除非系统内存紧张，否则，执行完onStartCommand()方法后，Service依然运行。停止Service必须手动调用stopSelf()（在Service中）或调用stopService()（在启动组件中）。

一旦调用了上述两种方法之一，系统会尽快destroy该Service。

若系统正在处理多个调用onStartCommand()请求，那么在启动一个请求时，不应当在此时停止该Service。为了避免这个问题，您可以调用stopSelf(int)方法，以确保请求停止的Service时最新的启动请求。这就是说，当调用stopSelf(int)方法时，传入的ID代表启动请求（该ID会传递至onStartCommand()），该ID与请求停止的ID一致。则如果在调用stopSelf(int)之前，Service收到一个新的Start请求，ID将无法匹配，Service并不会停止。

为了节省内存和电量，当Service完成其工作后将其stop很有必要。如有必要，可以在其他组件中调用stopService()方法，即便Service处于绑定状态，只要它回调过onStartCommand()，也应当主动停止该Service。

四、Service的生命周期

当Android面临内存匮乏的时候，可能会销毁掉你当前运行的Service，然后待内存充足的时候可以重新创建Service，Service被Android系统强制销毁并再次重建的行为依赖于Service中onStartCommand方法的返回值。我们常用的返回值有三种值，START_NOT_STICKY、START_STICKY和START_REDELIVER_INTENT，这三个值都是Service中的静态常量。

START_NOT_STICKY： 如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service，当然如果在其被杀掉之后一段时间又调用了startService，那么该Service又将被实例化。那什么情境下返回该值比较恰当呢？如果我们某个Service执行的工作被中断几次无关紧要或者对Android内存紧张的情况下需要被杀掉且不会立即重新创建这种行为也可接受，那么我们便可将 onStartCommand的返回值设置为START_NOT_STICKY。

举个例子，某个Service需要定时从服务器获取最新数据：通过一个定时器每隔指定的N分钟让定时器启动Service去获取服务端的最新数据。当执行到Service的onStartCommand时，在该方法内再规划一个N分钟后的定时器用于再次启动该Service并开辟一个新的线程去执行网络操作。假设Service在从服务器获取最新数据的过程中被Android系统强制杀掉，Service不会再重新创建，这也没关系，因为再过N分钟定时器就会再次启动该Service并重新获取数据。

START_STICKY： 如果返回START_STICKY，表示Service运行的进程被Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象，然后Android系统会尝试再次重新创建该Service，并执行onStartCommand回调方法，但是onStartCommand回调方法的Intent参数为null，也就是onStartCommand方法虽然会执行但是获取不到intent信息。如果你的Service可以在任意时刻运行或结束都没什么问题，而且不需要intent信息，那么就可以在onStartCommand方法中返回START_STICKY，比如一个用来播放背景音乐功能的Service就适合返回该值。

START_REDELIVER_INTENT： 如果返回START_REDELIVER_INTENT，表示Service运行的进程被Android系统强制杀掉之后，与返回START_STICKY的情况类似，Android系统会将再次重新创建该Service，并执行onStartCommand回调方法，但是不同的是，Android系统会再次将Service在被杀掉之前最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand方法中，这样我们就能读取到intent参数。只要返回START_REDELIVER_INTENT，那么onStartCommand重的intent一定不是null。如果我们的Service需要依赖具体的Intent才能运行（需要从Intent中读取相关数据信息等），并且在强制销毁后有必要重新创建运行，那么这样的Service就适合返回START_REDELIVER_INTENT。

参考：

http://www.codeceo.com/article/android-startservice-service.html

http://www.cnblogs.com/lwbqqyumidi/p/4181185.html

http://blog.csdn.net/vanpersie_9987/article/details/51360245