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需要定时从服务器获取最新数据：通过一个定时器每隔指定的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。

到此这篇关于android startservice的使用与service生命周期案例详解的文章就介绍到这了,更多相关android startservice的使用与service生命周期内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！