文档章节

剖析IntentService的运作机理

悠然红茶
 悠然红茶
发布于 2016/11/10 08:07
字数 2704
阅读 219
收藏 2
点赞 0
评论 0

剖析IntentService的运作机理

(本文以Android 5.1为准)

侯 亮


1 概述

在讲述Service机制的文章里,我们曾经稍微提起过IntentService,今天再来详细剖析一下它。说起来,IntentService只是一个处理异步请求的服务基类而已。当人们通过调用startService()启动IntentService时,实质上是向其发送了一个请求。而如果有多个地方同时向同一个IntentService发送请求的话,那么这些请求会被串行化处理。所以,IntentService常常用于执行那种“一次性处理”的工作。

IntentService的运作机理相对比较简单,而且从Android2.3(我手头最早的版本)到Android5.1,IntentService的实现代码一直就没怎么变动过,可见其稳定程度。

当然,我们既然说要详细剖析IntentService,就不可能仅仅讲这么点儿东西。我们可以挖得再深一点儿,看看IntentService到底是如何实现的,又是如何保证串行处理工作的。现在我们就开始吧。


2 先简单说说IntentService的运作

2.1 onCreate()中启动一个消息泵线程

我们先看一下IntentService的onCreate()函数:
【frameworks/base/core/java/android/app/IntentService.java】

@Override
public void onCreate() {
    super.onCreate();
    HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
    thread.start();

    mServiceLooper = thread.getLooper();
    mServiceHandler = new ServiceHandler(mServiceLooper);
}

可以看到,IntentService创建伊始就会启动一个消息泵线程HandlerThread,然后又创建了一个可以向这个消息泵线程传递消息的Handler(即ServiceHandler)。

ServiceHandler是IntentService的一个内嵌类,其定义如下:

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);  // 注意,不是stopService()!
    }
}

所以,上面的代码的逻辑意义就很明确了,那就是构造一个消息泵线程以及一个可以向这个泵传递消息的Handler。而后,当这个消息泵线程最终处理这个消息时,其实就是在回调IntentService的onHandleIntent()函数而已,并且在该回调函数返回后,handleMessage()会进一步调用stopSelf()结束service。注意,这里说“结束service”只是一种简略说法,实际的情况会稍微复杂一点儿,这个我们后文再细说。

2.2 onStartCommand()利用ServiceHandler向消息泵打入特殊消息

在紧随onCreate()函数之后,系统会调用到onStartCommand()函数,这个大家都很熟悉了。对于startService()动作而言,系统只会在service尚不存在的情况下,创建相应的service,并回调其onCreate()函数。以后,只要这个service没有被销毁,就不会重复再调用onCreate()了。不过,每次调用startService()都会导致走到onStartCommand()函数。IntentService的onStartCommand()函数的代码如下:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    onStart(intent, startId);
    return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}
@Override
public void onStart(Intent intent, int startId) {
    Message msg = mServiceHandler.obtainMessage();
    msg.arg1 = startId;
    msg.obj = intent;
    mServiceHandler.sendMessage(msg);
}

看起来,每当用户调用startService()启动IntentService,就会自动向其内部消息泵线程打入一条消息,该消息的.obj域记录着用户传来的intent,这个intent在handleMessage()里会进一步传递给onHandleIntent()。另外,请大家注意那个startId参数,这里我们先打个伏笔,后文还会细说。

2.3 实现你的onHandleIntent()函数

在IntentService.java文件里,onHandleIntent()只是做了简单的声明:

protected abstract void onHandleIntent(Intent intent);

其具体行为要看我们写的IntentService派生类怎么定义这个函数啦。

消息泵里的消息队列在先天上就维护了一条串行化的执行链。消息泵线程逐个摘取消息节点,回调每个节点的onHandleIntent()函数,一切都显得那么自然。现在我们可以画出如下示意图:

3 再深挖一下

有了以上这些基础知识,现在我们要再深挖一下了。

在消息队列中,消息的确被顺序排列了,可是在处理前一个消息时,调用的stopSelf()不是把service结束了吗?那它还怎么保证继续处理后续消息呢?可见,前文我们说的“IntentService还会自动执行stopSelf()关闭自己”的说法并不准确。问题的关键在于,ServiceHandler的handleMessage()里调用的是stopSelf(),而不是stopService()!它们是不一样的。

3.1 stopSelf()和stopService()是不一样的!

stopSelft()的函数定义如下:
【frameworks/base/core/java/android/app/Service.java】

public final void stopSelf(int startId) {
    if (mActivityManager == null) {
        return;
    }
    try {
        mActivityManager.stopServiceToken(
                new ComponentName(this, mClassName), mToken, startId);
    } catch (RemoteException ex) {
    }
}

请大家注意那个startId参数,这个参数是系统通过onStartCommand()传递给service的,也就是前文我们打伏笔的地方。要了解这个startId参数,我们得看一下AMS里的相关代码。

AMS中启动service的函数是startService,其代码截选如下:
【frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java】

public ComponentName startService(IApplicationThread caller, Intent service,
        String resolvedType, int userId) {
    . . . . . .
        . . . . . .
        ComponentName res = mServices.startServiceLocked(caller, service,
                resolvedType, callingPid, callingUid, userId);
        . . . . . .
    . . . . . .
}

【frameworks/base/services/core/java/com/android/server/am/ActiveServices.java】

ComponentName startServiceLocked(IApplicationThread caller,
        Intent service, String resolvedType,
        int callingPid, int callingUid, int userId) {
    . . . . . .
    ServiceRecord r = res.record;
    . . . . . .
    r.lastActivity = SystemClock.uptimeMillis();
    r.startRequested = true;
    r.delayedStop = false;
    r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
            service, neededGrants));
    . . . . . .
    . . . . . .
    return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}

也就是说,每当我们调用startService()启动一个服务时,不但会在其对应的ServiceRecord节点的pendingStarts里插入一个新的StartItem节点,而且会为这个StartItem节点生成一个新的id号,这个id号就是日后的startId啦。

生成id号时,采用的办法是最简单的加1操作,代码如下:
【frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java】

public int makeNextStartId() {
    lastStartId++;
    if (lastStartId < 1) {
        lastStartId = 1;
    }
    return lastStartId;
}

接下来,我们绘制一张调用关系图:

图中的sendServiceArgsLocked()会将r.pendingStarts列表中的StartItem节点转移到r.deliveredStarts列表中。这主要是因为启动service的动作本身是比较复杂的,有时候甚至会遇到目标service寄身的进程尚未启动的情况,此时就得先启动一个用户进程,而后再进一步启动service。要规划好这些异步的动作,我们常常需要把信息先记录进一个pending列表里,而后再在合适的时机将信息从pending列表里取出。

上图中最后调用的r.app.thread.scheduleServiceArgs()其实是向service所在的进程发出SERVICE_ARGS语义,语义中携带着刚取出的StartItem节点的id和intent信息。该语义最终导致执行到目标service的onStartCommand()。这个就和前文介绍onStartCommand()的地方契合起来了。

当onStartCommand()向消息泵线程打入消息时,startId就被记录进message里了。我们现在举个例子,假设几乎在同时有两个地方都调用startService()来启动同一个IntentService,此时很可能会形成两个StartItem和两个IntentService消息,画出示意图如下:

既然消息队列里的消息已经和AMS里的StartItem对应上了,那么在处理完消息后,调用stopSelf()时,应该也必须考虑到这种匹配关系。所以stopSelf()的参数就是startId。前文我们已经看到,stopSelf()内部是在调用:

        mActivityManager.stopServiceToken(
                new ComponentName(this, mClassName), mToken, startId);

stopServiceToken()的代码如下:
【frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java】

@Override
public boolean stopServiceToken(ComponentName className, IBinder token,
        int startId) {
    synchronized(this) {
        return mServices.stopServiceTokenLocked(className, token, startId);
    }
}

【frameworks/base/services/core/java/com/android/server/am/ActiveServices.java】

boolean stopServiceTokenLocked(ComponentName className, IBinder token, int startId) {
    . . . . . .
    ServiceRecord r = findServiceLocked(className, token, UserHandle.getCallingUserId());
    if (r != null) {
        if (startId >= 0) {
            ServiceRecord.StartItem si = r.findDeliveredStart(startId, false);
            if (si != null) {
                // 用while循环删除位于startId对应的StartItem节点以及其之前的所有节点
                while (r.deliveredStarts.size() > 0) {
                    ServiceRecord.StartItem cur = r.deliveredStarts.remove(0);
                    cur.removeUriPermissionsLocked();
                    if (cur == si) {
                        break;
                    }
                }
            }

            if (r.getLastStartId() != startId) {
                return false;    // 如果不是最后一个startItem节点,则直接return false了
            }

            if (r.deliveredStarts.size() > 0) {
                Slog.w(TAG, "stopServiceToken startId " + startId
                        + " is last, but have " + r.deliveredStarts.size()
                        + " remaining args");
            }
        }
        . . . . . .
        // 当最后一个startItem摘掉后,才真正结束service
        bringDownServiceIfNeededLocked(r, false, false);  
        . . . . . .
        return true;
    }
    return false;
}

这段代码的主要意思还是比较明确的,那就是按序从ServiceRecord的deliveredStarts列表中删除StartItem节点,直到所删除的是startId参数对应的StartItem节点,如果此时尚未抵达ServiceRecord内部记录的最后一个start Id号,则说明此次stopSelf()操作没必要进一步结束service,那么直接return false就可以了。只有在所删除的startItem节点的确是最后一个startItem节点时,才会调用bringDownServiceIfNeededLocked()去结束service。这就是为什么IntentService的ServiceHandler在处理完消息后,可以放心调用stopSelf()的原因。

那么,为什么要用一个while循环来删除位于startId对应的StartItem节点之前的所有节点呢?大家可以设想一下,如果service进程被异常kill了,那么它里面的消息队列肯定也就销毁了。可是在AMS一侧的ServiceRecord里,那些对应的StartItem节点还是存在的,就好像一个个孤儿一样。此时,如果用户再一次调用startService()启动了这个IntentService,那么系统最好能在处理完此次message后,一并将那些孤儿StartItem销毁。不过这只是我目前的一点儿猜想,实际上可能不大容易遇到这种情况。

3.2 说说setIntentRedelivery()

现在我们再来看看IntentService里其他一些细节。比如setIntentRedelivery()函数:
【frameworks/base/core/java/android/app/IntentService.java】

public void setIntentRedelivery(boolean enabled) {
    mRedelivery = enabled;
}

一般,我们可以在实现IntentService派生类时,在构造函数里调用这个函数。这里设置的mRedelivery成员会在onStartCommand()函数里影响最终的返回值,从而影响service的“重递送intent”的行为。

我们再列一次onStartCommand()的代码:

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

当mRedelivery为true,会返回START_REDELIVER_INTENT,这个值的意思是说,如果在onStartCommand()之后的某个时刻,该service对应的进程被kill了,那么系统会自动重启该service,并向onStartCommand()重新传入当初startService()时指定的intent。另外,在极端情况下,可能已经有多个地方startService()了,那么系统在重启service之后,应该会将自己记录的多个intent逐条传递回service,也就是说,有可能会执行多次onStartCommand()了。而当mRedelivery为false时,会返回START_NOT_STICKY,它表示如果在后续某个时刻,该service对应的进程被kill了,系统是不会自动重启该service的。


4 小结

有关IntentService的知识,我们就先说这么多,有兴趣的同学不妨对比代码看看。

© 著作权归作者所有

共有 人打赏支持
悠然红茶
粉丝 317
博文 19
码字总数 99747
作品 0
西安
高级程序员
Android IntentService详解

转载请注明出处:http://blog.csdn.net/vnanyesheshou/article/details/75125909 最近正在加深基础,看到个IntentService类,以前从来没有遇见过,更不知其用来干嘛的,所以就整理了一个dem...

VNanyesheshou
2017/07/15
0
0
Android异步加载全解析之IntentService

Android异步加载全解析之IntentService 搞什么IntentService 前面我们说了那么多,异步处理都使用钦定的AsyncTask,再不济也使用的Thread,那么这个IntentService是个什么鬼。 相对与前面我们...

eclipse_xu
2015/03/31
0
0
IntentService-你可能需要知道这些

Service作为Android四大组件之一,在我们的日常开发中占着不可或缺的一席,而轻量级的IntentService作为对Service的一个补充,也越来越收到大家的推崇,本博文就带大家来学习和分析下IntentS...

24K男
2017/09/27
0
0
IntentService类 和 异步任务(AsyncTask)

IntentService是一个Service类。 IntentService只有1个带String参数的构造方法,所以,在自定义类继承IntentService时,需要在自定义类中显式的调用IntentService带参数的构造方法,并且将自...

梦想家Peng
2016/03/03
56
0
Android Service和IntentService区别

一、关于Service组件 在Android四大组件中Service是唯一能够后台运行的服务,广播接收器是一个等待着的和观察者的角色,并不属于后台程序,此外,他的生命周期也非常短,在OnReceiver中不能超...

IamOkay
2014/11/23
0
0
IntentService的使用

service本身存在两个问题: 1)service不会专门启动一条单独的进程,service与它所在的应用位于同一个进程。 2)service也不是专门新的一条线程,不应该在service中处理耗时的操作。 Intent...

summerpxy
2013/11/27
0
0
Android中Service与IntentService的使用比较

该博客来自网络——————>> 稍微翻译理一理,这里主要是说IntentServic 不知道大家有没有和我一样,以前做项目或者练习的时候一直都是用Service来处理后台耗时操作,却很少注意到还有个I...

crystaltiger
2013/09/09
0
0
Android之Service与IntentService的比较

不知道大家有没有和我一样,以前做项目或者练习的时候一直都是用Service来处理后台耗时操作,却很少注意到还有个IntentService,前段时间准备面试的时候看到了一篇关于IntentService的解释,...

带梦想一7飞
2014/01/16
0
1
细谈编程语言创建的后台服务---my note

就拿c#编程语言来说吧: 用c#中创建一个windows服务非常简单,与windows服务相关的类都在System.ServiceProcess命名空间下。 每个服务都需要继承自ServiceBase类,并重写相应的启动、暂停、停...

crossmix
2016/03/03
35
0
Service vs IntentService

Service 在后台运行,但仍然运行于主线程,所已如果需要执行耗时的操作就需要在service中开启新的线程来执行任务 通过stopservice()或stopself()来终止 会阻塞主线程 IntentService 系统会单...

skyfly
2016/06/19
18
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

公众号推荐

阿里技术 书籍:《不止代码》

courtzjl
9分钟前
0
0
关于改进工作效率

1.给不同的业务线建立需求群,所有的数据需求都在群里面提。 2.对于特别难搞定的事情,到对应的技术哪去做,有问题随时沟通。 3.定期给工作总结形成方法论。 4.学习新的技术,尝试用新的方法...

Avner
16分钟前
0
0
关于thinkphp 框架开启路径重写,无法获取Authorization Header

今天遇到在thinkphp框架中获取不到header头里边的 Authorization ,后来在.htaccess里面加多一项解决,记录下: <IfModule mod_rewrite.c> Options +FollowSymlinks -Multiviews Rewrite......

殘留回憶
20分钟前
0
0
centos 使用yum安装nginx后如何添加模块 10

centos 使用yum安装nginx后如何添加模块 10 centos6.2版本,使用yum来安装了nginx,但是最近需要重新添加模块,所以就傻了,询问下有人知道怎么重新添加模块吗? PS:俺是新手,需要高手救助...

linjin200
23分钟前
0
0
dubbo 资料

dubbo资料网站: https://www.cnblogs.com/a8457013/p/7818925.html

zaolonglei
23分钟前
0
0
大型网站,你是如何架构的?

大型网站,你是如何架构的?

微小宝
26分钟前
0
0
javaScript选框的全选与取消

<div> <input type="button" value="全选" onclick="quan()"> <input type="button" value="取消" onclick="cancel()"> <input type="button" value="反选" onclick="reverse()"> <table> <t......

南桥北木
27分钟前
0
0
七牛云宫静:基于容器和大数据平台的持续交付平台

7 月 6 日上午,在 ArchSummit 2018 深圳站 | 全球架构师峰会上,七牛云工程效率部技术专家宫静分享了《基于容器和大数据平台的持续交付平台》为题的演讲。本文是对演讲内容的整理。
 
 本...

七牛云
34分钟前
1
0
Linux系统下如何查看某个命令的安装位置

1.which + 命令 会出现这个命令的路径,如果不是软链接的话,那么这就是此软件的安装路径;如果是软连接的话,那么进入下一步 2.进入上面的路径下,输入:ls -al 要查照的命令 会出现它的真是...

xiaomin0322
34分钟前
1
0
微信小程序富文本图片处理二

一、将富文本中图片的相对链接地址修改成绝对链接地址 //替换图片链接 data.content = data.content.replace(/<img [^>]*src=['"]([^'"]+)[^>]*>/gi, function (match......

tianma3798
38分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部