IntentService使用和原理总结

IntentService

之前项目中有一个需求是在打开app时自动导入用户短信中的行程，考虑到导入行程的行为不仅耗时且需要在导入完成后关闭服务，所以采用了IntentService的实现方式。

具体使用

public class ReadTripSmsService extends IntentService {

    public ReadTripSmsService() {
        super("ReadTripSmsService");
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        mContext = this;
        return super.onStartCommand(intent, flags, startId);
    }

    @Override
    protected void onHandleIntent(Intent intent) {
    	//需要异步处理的逻辑
        getSmsInPhone();
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
    }
}

1.需要在构造方法中传入一个线程名称。
2.在onHandleIntent()中处理耗时任务。

源码分析

在分析源码之前，我们先思考两个问题
1.IntentService是如何在内部创建线程的。
2.IntentService是如何顺序处理耗时任务的。
首先，我们先来看IntentService的构造方法：

public ReadTripSmsService() {
	super("ReadTripSmsService");
}

public IntentService(String name) {
	super();
	mName = name;
}

可以看到，我们传入的线程名称 “ReadTripSmsService” 在IntentService的构造方法中被保存到mName中，我们会想在某处肯定会调用到mName。再来从service生命周期的创建onCreate（）看

onCreate

@Override
    public void onCreate() {
        // TODO: It would be nice to have an option to hold a partial wakelock
        // during processing, and to have a static startService(Context, Intent)
        // method that would launch the service & hand off a wakelock.

        super.onCreate();
        //step 1
        HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
        thread.start();
		//step 2
        mServiceLooper = thread.getLooper();
        //step 3
        mServiceHandler = new ServiceHandler(mServiceLooper);
    }

1.创建一个工作线程，取名为"IntentService[" + mName + "]"并开启。（mName使命完成）。
2.获取工作线程中的Looper对象mServiceLooper。
3.创建一个ServiceHandler。
我们再来看一下ServiceHandler是个何方神圣。

private final class ServiceHandler extends Handler {
        public ServiceHandler(Looper looper) {
            super(looper);
        }

        @Override
        public void handleMessage(Message msg) {
            onHandleIntent((Intent)msg.obj);
            stopSelf(msg.arg1);
        }
    }

ServiceHandler继承了Handler并实现了handleMessage，当有消息发送过来，首先调用onHandleIntent（） 处理耗时任务，onHandleIntent是一个空方法，需要我们重写处理耗时任务，然后调用stopSelf（）退出服务，这就是IntentService可以在处理完耗时任务后主动退出的原因。

注：onHandleIntent（）在工作线程中，因为我们都知道要想在子线程中使用Handler必须创建Looper对象，实际上HandlerThread已经为我们做了这一点（HandlerThread的内部原理本章暂不分析，先了解有这么回事），因此mServiceLooper是在工作线程中循环读取消息的，所以消息分发到handleMessage一样是在子线程中，这样我们就理解了为什么需要在onHandleIntent（）中处理耗时任务。

onStartCommand()

public int onStartCommand(@Nullable Intent intent, int flags, int startId){
	onStart(intent, startId);
	return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}

public void onStart(@Nullable Intent intent, int startId) {
	Message msg = mServiceHandler.obtainMessage();
	msg.arg1 = startId;
	msg.obj = intent;
	mServiceHandler.sendMessage(msg);
}

IntentService的生命周期走到onStartCommand，内部调用onStart（），将startId即service的id和intent封装成一个message发送到消息队列中。此时，就与我们之前分析的handleMessage形成闭环。

onDestroy（）

@Override
    public void onDestroy() {
        mServiceLooper.quit();
    }

这里执行了Looper.quit(),最后实际调用了消息队列的quit（false）方法，所以，并不是安全退出，即使消息队列里有其他消息，也会强行退出不再处理其他消息。

到这里还没有结束，我们第二个问题还没有解决，那就是为什么多个任务同时进行的情况下会顺序执行。
场景：当我们第一次startService时，IntentService执行onHandleIntent,假设执行时长为7s，在执行到第3s时，我们又startService一次，又一次发送了一个消息，以此类推。
分析：我们第一次开启service时执行了onCreate，第二次和之后由于service已经存在，只会调用onstartCommand，所以所有的任务都是在一个线程中进行的，并且消息队列遵循先进先出原则，只有等到前一个消息处理结束之后才会处理下一个消息，这时有同学可能会有疑问，既然如此，肯定会执行stopself，那为什么只执行了一次onCreate呢，我第一次读IntentService源码时也有这种疑问，所以我点进stopSelf的源码中根据startId最后找到AMS.stopServiceToken->ActiveServices.stopServiceTokenLocked,发现：

boolean stopServiceTokenLocked(ComponentName className, IBinder token,
            int startId) {
        if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "stopServiceToken: " + className
                + " " + token + " startId=" + startId);
        ServiceRecord r = findServiceLocked(className, token, UserHandle.getCallingUserId());
        if (r != null) {
            if (startId >= 0) {
                // Asked to only stop if done with all work.  Note that
                // to avoid leaks, we will take this as dropping all
                // start items up to and including this one.
                ServiceRecord.StartItem si = r.findDeliveredStart(startId, false, false);
                if (si != null) {
                    while (r.deliveredStarts.size() > 0) {
                        ServiceRecord.StartItem cur = r.deliveredStarts.remove(0);
                        cur.removeUriPermissionsLocked();
                        if (cur == si) {
                            break;
                        }
                    }
                }

                if (r.getLastStartId() != startId) {
                    return false;
                }

                if (r.deliveredStarts.size() > 0) {
                    Slog.w(TAG, "stopServiceToken startId " + startId
                            + " is last, but have " + r.deliveredStarts.size()
                            + " remaining args");
                }
            }
            return true;
        }
        return false;
    }

看到源码注释，我才豁然开朗，原来只在完成所有任务后才会停止服务，它会根据startId来判断任务是否还在进行中，具体的逻辑我们就不细看了。

总结

IntentService是一个拥有自己工作线程的service，任务完成后会自行销毁，并且支持多任务顺序执行，适用于后台，顺序执行的应用场景。