Android中startService的使用及Service生命周期

Android中有两种主要方式使用Service，通过调用Context的startService方法或调用Context的bindService方法。本文仅仅探讨纯startService的使用。不涉及不论什么bindService方法调用的情况。假设想了解bindService的相关使用，请參见《Android中bindService的使用及Service生命周期》。

当我们通过调用了Context的startService方法后，我们便启动了Service，通过startService方法启动的Service会一直无限期地运行下去。仅仅有在外部调用Context的stopService或Service内部调用Service的stopSelf方法时。该Service才会停止运行并销毁。

要想使用Service。首先我们要继承自Service。然后重写例如以下方法:
onCreate, onStartCommand, onBind 和 onDestroy。

这几个方法都是回调方法。都是由Android操作系统在合适的时机调用的。而且须要注意的是这几个回调方法都是在主线程中被调用的。

onCreate: 运行startService方法时，假设Service没有运行的时候会创建该Service并运行Service的onCreate回调方法；假设Service已经处于运行中。那么运行startService方法不会运行Service的onCreate方法。

也就是说假设多次运行了Context的startService方法启动Service，Service方法的onCreate方法仅仅会在第一次创建Service的时候调用一次。以后均不会再次调用。

我们能够在onCreate方法中完毕一些Service初始化相关的操作。

onStartCommand: 在运行了startService方法之后。有可能会调用Service的onCreate方法，在这之后一定会运行Service的onStartCommand回调方法。也就是说，假设多次运行了Context的startService方法，那么Service的onStartCommand方法也会对应的多次调用。

onStartCommand方法非常重要。我们在该方法中依据传入的Intent參数进行实际的操作。比方会在此处创建一个线程用于下载数据或播放音乐等。

onBind: Service中的onBind方法是抽象方法。所以Service类本身就是抽象类，也就是onBind方法是必须重写的。即使我们用不到。在通过startService使用Service时，我们在重写onBind方法时，仅仅须要将其返回null就可以。

onBind方法主要是用于给bindService方法调用Service时才会使用到。

onDestroy: 通过startService方法启动的Service会无限期运行，仅仅有当调用了Context的stopService或在Service内部调用stopSelf方法时。Service才会停止运行并销毁，在销毁的时候会运行Service回调函数。

我们为了探究通过startService方法启动的Service的生命周期以验证上面对各个回调函数方法的描写叙述。写了例如以下的一个測试案例。

首先创建一个服务类TestService，该类继承自Service。代码例如以下:

package com.ispring.startservicedemo;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;

public class TestService extends Service {

    @Override
    public void onCreate() {
        Log.i("DemoLog","TestService -> onCreate, Thread ID: " + Thread.currentThread().getId());
        super.onCreate();
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Log.i("DemoLog", "TestService -> onStartCommand, startId: " + startId + ", Thread ID: " + Thread.currentThread().getId());
        return START_STICKY;
    }

    @Override
    public IBinder onBind(Intent intent) {
        Log.i("DemoLog", "TestService -> onBind, Thread ID: " + Thread.currentThread().getId());
        return null;
    }

    @Override
    public void onDestroy() {
        Log.i("DemoLog", "TestService -> onDestroy, Thread ID: " + Thread.currentThread().getId());
        super.onDestroy();
    }
}

我们在TestService的各个回调方法中仅仅是简单打印出了对应的信息。并没有做非常多复杂的处理操作。

然后我们在Activity中调用该Serivce，Activity中对应的代码例如以下:

package com.ispring.startservicedemo;

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.util.Log;


public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Log.i("DemoLog", "Thread ID: " + Thread.currentThread().getId());

        Log.i("DemoLog", "before test startService");

        //连续启动Service
        Intent intent1 = new Intent(this, TestService.class);
        startService(intent1);
        Intent intent2 = new Intent(this, TestService.class);
        startService(intent2);
        Intent intent3 = new Intent(this, TestService.class);
        startService(intent3);

        //停止Service
        Intent intent4 = new Intent(this, TestService.class);
        stopService(intent4);

        //再次启动Service
        Intent intent5 = new Intent(this, TestService.class);
        startService(intent5);

        Log.i("DemoLog", "after test startService");
    }
}

我们在Activity中，首先连续三次调用了Activity的startService方法以启动Service，然后调用Activity的stopService方法停止Service，然后又通过调用Activity的startService方法启动Service。

运行程序的输出结果例如以下:
这里写图片描写叙述

我们分析一下上面的输出结果，首先打印出了主线程的ID是1，然后我们发现后面全部在回调函数中打印出的运行线程的ID也就是1。这就说明了Service中的各个回调方法是运行在主线程中的。其次我们能够发如今我们连续调用了三次startService方法之后，仅仅触发了一次onCreate回调方法。触发了三次onStartCommand方法，在onStartCommand中我们能够读取到通过startService方法传入的Intent对象，而且这三次的startId都不同，各自是1,2,3，每次调用startService都会自己主动分配一个startId。startId能够用来区分不同的startService的调用，普通情况下startId都是从1開始计数。以后每次调用startService之后startId自己主动加一递增。

之后我们又调用了Activity的stopService(intent4)方法用于停止Service，通过输出结果我们发现Service运行了onDestroy方法，普通情况下我们能够在onDestroy方法中运行一些资源释放的操作。运行完onDestroy之后该Service的实例就销毁了。尽管我们之前调用了三次startService方法，可是仅仅要调用一次stopService就能够让运行中的Service停止运行并销毁。

最后我们再次通过startService(intent5)启动Service时，通过输出结果我们发现再次运行了Service的onCreate方法，这说明Service在通过stopService销毁之后又一次创建了。并随之再次调用onStartCommand回调方法。而且startId再次从1開始计数。

最后须要注意的是我们在Activity中操作Service的開始和结尾处分别写了两句输出代码，各自是

Log.i("DemoLog", "before test startService");

和

Log.i("DemoLog", "after test startService");

可是我们再看一下输出结果会发现。程序直接上来在输出了before test startService之后。却马上输出了after test startService，在这之后才是TestService内部各个回调方法的输出。这说明startService()方法和stopService()方法在运行完后马上返回了，也就是这两个方法都不是堵塞式的，启动service和停止service都是异步操作，startService()、stopService()都是将intent对象发送给Android Framework，然后Framework层异步地启动、停止Service。

我们用一张图来概括一下通过startService启动的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须要定时从server获取最新数据：通过一个定时器每隔指定的N分钟让定时器启动Service去获取服务端的最新数据。当运行到Service的onStartCommand时，在该方法内再规划一个N分钟后的定时器用于再次启动该Service并开辟一个新的线程去运行网络操作。假设Service在从server获取最新数据的过程中被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。

posted @ 2017-08-09 12:47 clnchanpin 阅读(2738) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部