亲宝软件园·资讯

展开

Android Service完整实现流程分析

失落夏天 人气:0

前言

一开始的目标是解决各种各样的ANR问题的,我们知道,ANR总体上分有四种类型,这四种类型有三种是和四大组件相对应的,所以,如果想了解ANR发生的根因,对安卓四大组件的实现流程是必须要了解的,都不明白ANR如何触发的,怎么能完美的解决ANR的问题呢?

所以会写一系列的文章,来分析四大组建的实现原理,同时也顺带讲解四种类型的ANR是如何发生的。

本篇主要介绍service的完整实现流程,下一篇文章介绍Service中的ANR是如何产生的。

一.APP侧启动Service

其实启动service和启动Activity是很相似的,都是APP通知系统侧,由系统侧完成的整个流程。

1.1前台和后台启动

无论是Activity,还是service,还是Application,都继承自Context的抽象类,所以可以使用Context的各种功能,就比如这了要介绍的启动前台/后台service。

Context在安卓中,使用了一种典型的代理模式,我们调用的startService或者startForegroundService方法,最终都会委托给ContextImpl中的startService和startForegroundService来处理的。我们就来看下ContextImpl中的这两个方法:

@Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, false, mUser);
    }
    @Override
    public ComponentName startForegroundService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, true, mUser);
    }

果然和我猜测的差不多,无论前台还是后台启动,其实最终都会走到一个方法中,只是配置参数的区别而已。最终都会走执行startServiceCommon方法。

1.2startServiceCommon

该方法中,通过binder通知系统的AMS完成对应的service的启动操作:

 ComponentName cn = ActivityManager.getService().startService(
                    mMainThread.getApplicationThread(), service,
                    service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
                    getOpPackageName(), getAttributionTag(), user.getIdentifier());

接下来,我们就看下系统侧是如何处理Service启动流程的。

二.系统侧分发处理Service的启动逻辑

系统侧的处理我主要分为3块来讲:

1.系统接受APP侧的通知并转发

2.系统侧委托ActiveServices负责完成的处理流程

3.收到APP侧执行完成的回调,进行收尾操作

2.1AMS接受启动service的通知

APP侧持有system_server进程的binder,上面讲到,它会通过binder方法startService完成对系统侧的通知。所以AMS的startService会收到这个通知。

我们看下代码,发现AMS会把整个service的逻辑全部交由ActiveServices来处理,代码如下:

 try {
                res = mServices.startServiceLocked(caller, service,
                        resolvedType, callingPid, callingUid,
                        requireForeground, callingPackage, callingFeatureId, userId);
            } finally {
                Binder.restoreCallingIdentity(origId);
            }

系统代码startServiceLocked方法中,代码虽然很长,但是却遵循着一个不变的宗旨:位语句,即前面处理各种异常的分支逻辑,把核心流程留到方法的最终来处理。

所以我们直接看startServiceLocked方法的最后一部分即可:

final ComponentName realResult =
                startServiceInnerLocked(r, service, callingUid, callingPid, fgRequired, callerFg,
                allowBackgroundActivityStarts, backgroundActivityStartsToken);

startServiceInnerLocked方法中,处理逻辑也是比较简单的,最终会交给bringUpServiceLocked方法来进行处理。而bringUpServiceLocked方法中则最终会交给realStartServiceLocked完成整个流程。好像系统代码都喜喜欢用realStart,Activity启动的流程中也有一个方法叫realStartActivity。

2.2realStartServiceLocked流程

realStartServiceLocked方法中,我们总结为三个流程:

1.bumpServiceExecutingLocked,启动超时检查。

2.thread.scheduleCreateService通知APP一侧去创建Service。

3.sendServiceArgsLocked通知APP执行Service的生命流程。

private void realStartServiceLocked(ServiceRecord r, ProcessRecord app,
            IApplicationThread thread, int pid, UidRecord uidRecord, boolean execInFg,
            boolean enqueueOomAdj) throws RemoteException {
        //1.启动超时检查
        bumpServiceExecutingLocked(r, execInFg, "create", null /* oomAdjReason */);
        ...
        //2.通知APP创建service
            thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
                    app.mState.getReportedProcState());
            r.postNotification();
            created = true;
        ...
        //3.通知执行service生命流程
        sendServiceArgsLocked(r, execInFg, true);
       ...
    }

三.系统侧通知APP启动Service

一般情况下,APP侧会收到系统侧发过来两种类型的通知,

第一种:创建Service的任务通知

第二种:执行Service生命流程的通知,通知Service执行onStartCommand方法。

ApplicationThread接受通知并创建Service

系统侧持有APP侧的binder,会通过scheduleCreateService这个binder方法通知APP一侧进行相应的操作。而APP侧,完成这个工作接收的就是ApplicationThread中的scheduleCreateService方法。该方法收到通知后,通过handler切换到主线程处理:

 public final void scheduleCreateService(IBinder token,
                ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
            updateProcessState(processState, false);
            CreateServiceData s = new CreateServiceData();
            s.token = token;
            s.info = info;
            s.compatInfo = compatInfo;
            sendMessage(H.CREATE_SERVICE, s);
        }

handle中,会切换到主线程执行ActivityThread的handleCreateService方法。

主要执行了如下的几段逻辑:

1.如果是首次创建App进程的话,则需要重新创建Application;

2.创建Service对象;

3.调用service的attach方法进行关联;

4.调用service的onCreate生命周期方法;

5.创建完成后,通过serviceDoneExecuting通知系统侧创建完成。

try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            final java.lang.ClassLoader cl;
            if (data.info.splitName != null) {
                cl = packageInfo.getSplitClassLoader(data.info.splitName);
            } else {
                cl = packageInfo.getClassLoader();
            }
            service = packageInfo.getAppFactory()
                    .instantiateService(cl, data.info.name, data.intent);
            ContextImpl context = ContextImpl.getImpl(service
                    .createServiceBaseContext(this, packageInfo));
            if (data.info.splitName != null) {
                context = (ContextImpl) context.createContextForSplit(data.info.splitName);
            }
            if (data.info.attributionTags != null && data.info.attributionTags.length > 0) {
                final String attributionTag = data.info.attributionTags[0];
                context = (ContextImpl) context.createAttributionContext(attributionTag);
            }
            // Service resources must be initialized with the same loaders as the application
            // context.
            context.getResources().addLoaders(
                    app.getResources().getLoaders().toArray(new ResourcesLoader[0]));
            context.setOuterContext(service);
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManager.getService());
            service.onCreate();
            mServicesData.put(data.token, data);
            mServices.put(data.token, service);
            try {
                ActivityManager.getService().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
            } catch (RemoteException e) {
                throw e.rethrowFromSystemServer();
            }
        }

ApplicationThread接受通知并执行Service的生命流程

同样的,这里完成接受的是,仍然是ApplicationThread中的方法。这个流程中的接受方法是scheduleServiceArgs方法。

ApplicationThread中,收到通知后,通过handler把任务转交到主线程。

 public final void scheduleServiceArgs(IBinder token, ParceledListSlice args) {
            List<ServiceStartArgs> list = args.getList();
            for (int i = 0; i < list.size(); i++) {
                ServiceStartArgs ssa = list.get(i);
                ServiceArgsData s = new ServiceArgsData();
                s.token = token;
                s.taskRemoved = ssa.taskRemoved;
                s.startId = ssa.startId;
                s.flags = ssa.flags;
                s.args = ssa.args;
                sendMessage(H.SERVICE_ARGS, s);
            }
        }

接下来handler中切换到主线程会执行ActivityThread的handleServiceArgs方法。

handleServiceArgs方法主要会完成以下几件事:

1.找到对应的service,调用起onStartCommand方法;

2.通知系统侧回调完成。

private void handleServiceArgs(ServiceArgsData data) {
        CreateServiceData createData = mServicesData.get(data.token);
        Service s = mServices.get(data.token);
        if (s != null) {
            try {
                if (data.args != null) {
                    data.args.setExtrasClassLoader(s.getClassLoader());
                    data.args.prepareToEnterProcess(isProtectedComponent(createData.info),
                            s.getAttributionSource());
                }
                int res;
                if (!data.taskRemoved) {
                    res = s.onStartCommand(data.args, data.flags, data.startId);
                } else {
                    s.onTaskRemoved(data.args);
                    res = Service.START_TASK_REMOVED_COMPLETE;
                }
                QueuedWork.waitToFinish();
                try {
                    ActivityManager.getService().serviceDoneExecuting(
                            data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
                } catch (RemoteException e) {
                    throw e.rethrowFromSystemServer();
                }
            } catch (Exception e) {
                if (!mInstrumentation.onException(s, e)) {
                    throw new RuntimeException(
                            "Unable to start service " + s
                            + " with " + data.args + ": " + e.toString(), e);
                }
            }
        }
    }

发我们发现,不论是创建service,还是通知执行service的生命流程,最终都执行了一个完成的通知,这有何意图呢?是的,这个意图就是和ANR相关的,我们下一章来讲了。

四.总结

前面一一讲了实现的原理,我们最后再来做一个总结,尽量用一张图+几句话的方式来概括。

1.无论前台启动还是后台启动,最终都会走到ContextImpl这个最终实现类中的方法,完成和AMS的交互。

2.AMS中主要是ActiveServices完成的整个流程。其核心方法是realStartServiceLocked。

他首先启动一个延时消息,通过延时消息进行超时的监测。

然后通知APP去生成Service。

通知APP侧去完成Service的生命周期流程onStartCommand。

3.收到APP侧执行完成的通知后,则取消注册延时消息。

加载全部内容

相关教程
猜你喜欢
用户评论