Android10.0 Service启动源码解析

本文出自门心叼龙的博客,属于原创类容,转载请注明出处。

Service的启动流程的还是比较简单的,不像Activity那么复杂,相关联的类和方法都少了很多,不像Activity启动流程里面走着走着就会迷失方向,源码分析这是加强Android内功修炼的必修课,分析了几个流程之后,你就会觉得也不过如此,因为他们的套路都是一样的,大体的实现思想都是相通的,只是具体的代码实现不同罢了。

在上一篇文章我们主要分析了Android10.0 Activity的启动过程,今天我们主要来探索Service的启动过程,本来打算先从5.0开始,然后在分析最新版10.0的启动过程,结果让我失望了,10.0的启动过程和5.0的是方法调用链是一样的,只是有些方法的代码逻辑有些小的改动,它不像Activity的启动流程变化那么大,这说明当时Service启动这块的代码逻辑写的还是非常不错的,Android已经迭代到10了经历了那么版本,这块的代码还是那么的完美稳定,没有什么需要大的改造的地方,10.0中有些小变化会在下面的详解过程会提到,既然5.0和10.0差别不大,索性就以5.0作为研究版本写了这篇文章。

Service是Android四大组件中排行老二,地位仅次于Activity,Activity位于前台向用户展示界面;Service位于后台不可见,但是它承担了大部分的的数据处理工作,主要为其他组件提供后台服务,监控其他组件的运行状态。

Activity中的流程

Service的启动是从Activity的startService方法开始的,这个方法是从他的父类ContextWrapper继承而来的,下面这是Activity的继承关系图:


Android10.0 Service启动源码解析_第1张图片
在这里插入图片描述

从上图我们很清晰的看到,Activity继承了ContextThemeWraper,而ContextThemeWraper又继承了ContextWrawper,startService方法正是ContextWraper所提供的,如下所示:


Android10.0 Service启动源码解析_第2张图片
在这里插入图片描述

ContextWrapter不但提供了开启服务的startService的方法,而且还提供了停止服务的stopService方法、绑定服务的bindService方法、Activity启动的startActivity方法、广播注册的registerReceiver方法、广播发送的sendBroadcast方法等,Context从英文翻译过来是环境,上下文的意思,它在整个Android操作系统中有着举足轻重的作用,在我们平时的应用开发过程中无处不在的Context,几乎随处可见,因为他是维持各大组件正常工作的核心功能类,它提供了一些系统级别的最基本的操作。

从上面代码的515行,我们看到ContextWraper的startService方法内部调用了mBase的startService方法,mBase的类型是ContextImpl, Activity在创建的时候通过attach方法给mBase变量赋值的,具体代码如下:

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
       ...

        Activity activity = null;
        try {
            java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
            //注释1
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
            StrictMode.incrementExpectedActivityCount(activity.getClass());
            r.intent.setExtrasClassLoader(cl);
            r.intent.prepareToEnterProcess();
            if (r.state != null) {
                r.state.setClassLoader(cl);
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(activity, e)) {
                throw new RuntimeException(
                    "Unable to instantiate activity " + component
                    + ": " + e.toString(), e);
            }
        }

        try {
            Application app = r.packageInfo.makeApplication(false, mInstrumentation);

            if (localLOGV) Slog.v(TAG, "Performing launch of " + r);
            if (localLOGV) Slog.v(
                    TAG, r + ": app=" + app
                    + ", appName=" + app.getPackageName()
                    + ", pkg=" + r.packageInfo.getPackageName()
                    + ", comp=" + r.intent.getComponent().toShortString()
                    + ", dir=" + r.packageInfo.getAppDir());

            if (activity != null) {
                //注释2
                Context appContext = createBaseContextForActivity(r, activity);
                CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
                Configuration config = new Configuration(mCompatConfiguration);
                if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "
                        + r.activityInfo.name + " with config " + config);
                //注释3
                activity.attach(appContext, this, getInstrumentation(), r.token,
                        r.ident, app, r.intent, r.activityInfo, title, r.parent,
                        r.embeddedID, r.lastNonConfigurationInstances, config,
                        r.voiceInteractor);

                if (customIntent != null) {
                    activity.mIntent = customIntent;c
                }
              ...
            

ActivityThread的performLaunchActivity方法是不是很熟悉,这是前面文章Activity启动流程中所讲到最重要的一个方法,Activity的创建,Application的创建都是有它来完成的,注释1处通过反射创建了一个activity,注释2处是上下文appContext的创建,注释3 activity调用了attach方法给mBase变量赋值。

注释2处appContext对象是由createBaseContextForActivity创建的,具体代码实现如下:

private Context createBaseContextForActivity(ActivityClientRecord r,
            final Activity activity) {
        //注释1    
        ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
        appContext.setOuterContext(activity);
        Context baseContext = appContext;

        final DisplayManagerGlobal dm = DisplayManagerGlobal.getInstance();
        try {
            IActivityContainer container =
                    ActivityManagerNative.getDefault().getEnclosingActivityContainer(r.token);
            final int displayId =
                    container == null ? Display.DEFAULT_DISPLAY : container.getDisplayId();
            if (displayId > Display.DEFAULT_DISPLAY) {
                Display display = dm.getRealDisplay(displayId, r.token);
                baseContext = appContext.createDisplayContext(display);
            }
        } catch (RemoteException e) {
        }
        ...
        return baseContext;

在以上代码的注释1处很清楚的看到 appContext 的类型就是ContextImpl,并且是由它的静态方法 createActivityContext创建的,创建完毕通过activity的attach方法给mBase赋值了。通过这些探索就是为了证实mBase的实现就是ContextImpl,现在我回到之前的启动流程mBase.startServcie(service)这一行,其实就是调用了ContextImpl的startService方法,我们继续看该方法的具体实现:

@Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, mUser);
    }
    private ComponentName startServiceCommon(Intent service, UserHandle user) {
        try {
            validateServiceIntent(service);
            service.prepareToLeaveProcess();
            //注释1
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), user.getIdentifier());
            if (cn != null) {
                if (cn.getPackageName().equals("!")) {
                    throw new SecurityException(
                            "Not allowed to start service " + service
                            + " without permission " + cn.getClassName());
                } else if (cn.getPackageName().equals("!!")) {
                    throw new SecurityException(
                            "Unable to start service " + service
                            + ": " + cn.getClassName());
                }
            }
            return cn;
        } catch (RemoteException e) {
            return null;
        }
    }

ContextImpl中startService方法会调用startServiceCommon方法,而startServiceCommon方法又会在注释1处调用ActivityManagerNative.getDefault()对象来启动一个服务,注意了这块的逻辑在Android10.0中是这式样的:

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

很显然获取服务这块有所变化,在5.0中是由ActivityManagerNative来完成的,在10.0中这个工作交给ActivityManager了,5.0和10.0最主要的变化就在这里,但是他们最终的逻辑都是一样的,最后都走ActivityManagerService的startService方法,此外,其他的逻辑基本没有什么大的改变,我们还是以5.0为研究版本,继续往下走。

在前面的分析Activity启动的时候我们知道ActivityManagerNative.getDefault()对象其实就是ActivityManagerService,此时Service的启动流程直接就走到了ActivityManagerService中,想必很多人还是不很清楚方法的调用流程怎么就过渡到了ActivityManagerService,其实这里用到了Android跨进程通信技术Binder,下面我们看看他的工作原理,搞清楚是怎么由ActivityManagerNative.getDefault()对象的startService方法过渡到ActivityManagerService的startService方法,ActivityManagerNative的getDefault方法的代码实现如下:

static public IActivityManager getDefault() {
       return gDefault.get();
}
private static final Singleton gDefault = new Singleton() {
        //注释1
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            //注释2
            IActivityManager am = asInterface(b);
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };   
static public IActivityManager asInterface(IBinder obj) {
        if (obj == null) {
            return null;
        }
        IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            //注释3
            return in;
        }
        //注释4
        return new ActivityManagerProxy(obj);
    }     

ActivityManagerNative中的getDefault方法很简单只有一行gDefault.get,而gDefault就是Singleton,他是一个单例对象,当调用它的get方法的时候就会执行注释1处onCreate方法,首先通过ServiceManager的getService方法获取了一个Binder,然后在注释2处把这个binder交给了asInterface方法、该方法的主要作用是将服务端binder对象转换为客户端所需要的IActivityManager 接口对象,如果在客户端和服务端在同一进程就会返回本地接口IActivityManager的实现对象,否则就会返回一个ActivityManagerProxy类型的代理对象,很显然该方法最后直接返回的就是一个代理对象ActivityManagerProxy,因为此时需要进行跨进程调用。因此ActivityManagerNative.getDefault()最终获取的是一个代理对象ActivityManagerProxy,紧着会调用这个对象ActivityManagerProxy的startService方法,方法实现如下:

 public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, int userId) throws RemoteException
    {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeStrongBinder(caller != null ? caller.asBinder() : null);
        service.writeToParcel(data, 0);
        data.writeString(resolvedType);
        data.writeInt(userId);
        //注释1
        mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);
        reply.readException();
        ComponentName res = ComponentName.readFromParcel(reply);
        data.recycle();
        reply.recycle();
        return res;
    }

startService方法会把传递过来的参数进行用Parcel 进行封装,然后在注释1处会调用mRemote的transact方法进行远程方法调用,mRemote对象就是我们前面代码注释4处实例化ActivityManagerProxy对象的时候通过构造方法传递给它的服务端Binder对象。此时客户端会处于挂起状态,ActivityManagerNative的实现类ActivityManagerService的onTransact方法响应,该方法的具体实现如下:

    @Override
    public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
            throws RemoteException {
        switch (code) {
         case START_SERVICE_TRANSACTION: {
            data.enforceInterface(IActivityManager.descriptor);
            IBinder b = data.readStrongBinder();
            IApplicationThread app = ApplicationThreadNative.asInterface(b);
            Intent service = Intent.CREATOR.createFromParcel(data);
            String resolvedType = data.readString();
            int userId = data.readInt();
            //注释1
            ComponentName cn = startService(app, service, resolvedType, userId);
            reply.writeNoException();
            ComponentName.writeToParcel(cn, reply);
            return true;
        }

onTransact方法响应后会从参数data中解析startService方法所需要的参数,然后在注释1处会调用它的startService方法进行启动服务的操作,至此启动服务的操作由客户端进程切换到了服务端进程,实现了方法的跨进行调用,接下来的我们看ActivityManagerService的startService的方法实现,方法实现如下:

ActivityManagerService的流程

 @Override
    public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, int userId) {
        enforceNotIsolatedCaller("startService");
        // Refuse possible leaked file descriptors
        if (service != null && service.hasFileDescriptors() == true) {
            throw new IllegalArgumentException("File descriptors passed in Intent");
        }

        if (DEBUG_SERVICE)
            Slog.v(TAG, "startService: " + service + " type=" + resolvedType);
        synchronized(this) {
            final int callingPid = Binder.getCallingPid();
            final int callingUid = Binder.getCallingUid();
            final long origId = Binder.clearCallingIdentity();
            //注释1
            ComponentName res = mServices.startServiceLocked(caller, service,
                    resolvedType, callingPid, callingUid, userId);
            Binder.restoreCallingIdentity(origId);
            return res;
        }
    }

该方法也不长,在最后ActivityManagerService会通过mServices来完成后续的启动操作,mServices的类型是ActiveServices,他是辅助ActivityManagerService进行Service管理的辅助类,包括Service的启动,绑定,停止等。在startService方法的尾部会调用ActiveServices的startServiceLocked方法,该方法的实现如下:

ActiveServices的流程

ComponentName startServiceLocked(IApplicationThread caller,
            Intent service, String resolvedType,
            int callingPid, int callingUid, int userId) {
        ....
        ServiceRecord r = res.record;

        if (!mAm.getUserManagerLocked().exists(r.userId)) {
            Slog.d(TAG, "Trying to start service with non-existent user! " + r.userId);
            return null;
        }

        NeededUriGrants neededGrants = mAm.checkGrantUriPermissionFromIntentLocked(
                callingUid, r.packageName, service, service.getFlags(), null, r.userId);
        if (unscheduleServiceRestartLocked(r, callingUid, false)) {
            if (DEBUG_SERVICE) Slog.v(TAG, "START SERVICE WHILE RESTART PENDING: " + r);
        }
        r.lastActivity = SystemClock.uptimeMillis();
        r.startRequested = true;
        r.delayedStop = false;
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                service, neededGrants));

        final ServiceMap smap = getServiceMap(r.userId);
        boolean addToStarting = false;
        ...
        return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }

在 ActiveServices的startServiceLocked方法的最后会把后续的启动工作交给startServiceInnerLocked方法来处理,它的代码实现如下所示:

ComponentName startServiceInnerLocked(ServiceMap smap, Intent service,
            ServiceRecord r, boolean callerFg, boolean addToStarting) {
        ProcessStats.ServiceState stracker = r.getTracker();
        if (stracker != null) {
            stracker.setStarted(true, mAm.mProcessStats.getMemFactorLocked(), r.lastActivity);
        }
        r.callStart = false;
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startRunningLocked();
        }
        //注释1
        String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false);
        if (error != null) {
            return new ComponentName("!!", error);
        }

        if (r.startRequested && addToStarting) {
            boolean first = smap.mStartingBackground.size() == 0;
            smap.mStartingBackground.add(r);
            r.startingBgTimeout = SystemClock.uptimeMillis() + BG_START_TIMEOUT;
            if (DEBUG_DELAYED_SERVICE) {
                RuntimeException here = new RuntimeException("here");
                here.fillInStackTrace();
                Slog.v(TAG, "Starting background (first=" + first + "): " + r, here);
            } else if (DEBUG_DELAYED_STARTS) {
                Slog.v(TAG, "Starting background (first=" + first + "): " + r);
            }
            if (first) {
                smap.rescheduleDelayedStarts();
            }
        } else if (callerFg) {
            smap.ensureNotStartingBackground(r);
        }

        return r.name;
    }   

在上述代码的注释1处会继续调用bringUpServiceLocked方法,它的源码如下:

private final String bringUpServiceLocked(ServiceRecord r,
            int intentFlags, boolean execInFg, boolean whileRestarting) {
   
        final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
        final String procName = r.processName;
        ProcessRecord app;

        if (!isolated) {
            app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
            if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
                        + " app=" + app);
            if (app != null && app.thread != null) {
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                    //注释1
                    realStartServiceLocked(r, app, execInFg);
                    return null;
                } catch (RemoteException e) {
                    Slog.w(TAG, "Exception when starting service " + r.shortName, e);
                }

                // If a dead object exception was thrown -- fall through to
                // restart the application.
            }
        } else {
            // If this service runs in an isolated process, then each time
            // we call startProcessLocked() we will get a new isolated
            // process, starting another process if we are currently waiting
            // for a previous process to come up.  To deal with this, we store
            // in the service any current isolated process it is running in or
            // waiting to have come up.
            app = r.isolatedProc;
        }
    ...
        return null;
    }

在bringUpServiceLocked方法的注释1处会调用realStartServiceLocked方法,从名字上看来该方法应该会最终完成服务的启动工作,它的具体实现如下:

 private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
        ...
        boolean created = false;
        try {
            String nameTerm;
            int lastPeriod = r.shortName.lastIndexOf('.');
            nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
            if (LOG_SERVICE_START_STOP) {
                EventLogTags.writeAmCreateService(
                        r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
            }
            synchronized (r.stats.getBatteryStats()) {
                r.stats.startLaunchedLocked();
            }
            mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
            app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            //注释1
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            r.postNotification();
            created = true;
        } catch (DeadObjectException e) {
            Slog.w(TAG, "Application dead when creating service " + r);
            mAm.appDiedLocked(app);
        } finally {
            if (!created) {
                app.services.remove(r);
                r.app = null;
                scheduleServiceRestartLocked(r, false);
                return;
            }
        }
        requestServiceBindingsLocked(r, execInFg);

        updateServiceClientActivitiesLocked(app, null, true);

        // If the service is in the started state, and there are no
        // pending arguments, then fake up one so its onStartCommand() will
        // be called.
        if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
            r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                    null, null));
        }
        //注释2
        sendServiceArgsLocked(r, execInFg, true);
        ...
    }

在realStartServiceLocked方法中首先会调用注释1处app.thread对象的scheduleCreateService方法来完成Servic的创建和onCreate方法的调用,然后在注释2处会调用sendServiceArgsLocked方法完成后续的处理工作,如onStartCommand方法的执行,在分析Activity启动流程的时候我们知道app.thread对象就是ApplicationThread,他是ActivityThread的一个内部类,其本质也是一个Bidner,因此scheduleCreateService方法调用后,启动Service的流程就由服务端进程切换到了客户端进程,接下来我们看ApplicationThread的scheduleCreateService方法实现:

ActivityThread的流程

 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);
        }

ApplicationThread的scheduleCreateService方法的内部实现很简单,就发送了一个CREATE_SERVICE类型的消息,这个消息会被ActivityThread的mH消息处理器所接收,之后会调用ActivityThread的方法handleCreateService进行处理,该方法的实现如下:

 private void handleCreateService(CreateServiceData data) {
        // If we are getting ready to gc after going to the background, well
        // we are back active so skip it.
        unscheduleGcIdler();

        LoadedApk packageInfo = getPackageInfoNoCheck(
                data.info.applicationInfo, data.compatInfo);
        Service service = null;
        try {
            java.lang.ClassLoader cl = packageInfo.getClassLoader();
            //注释1
            service = (Service) cl.loadClass(data.info.name).newInstance();
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to instantiate service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }

        try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
            //注释2
            ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
            context.setOuterContext(service);
            //注释3
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            //注释4
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManagerNative.getDefault());
            //注释5
            service.onCreate();
            mServices.put(data.token, service);
            try {
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, 0, 0, 0);
            } catch (RemoteException e) {
                // nothing to do.
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to create service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }
    }

在handleCreateService方法中代码还是很精炼的,主要完成了以下几个工作:

  • 1.在注释1处通过反射完成了Service的创建
  • 2.在注释2处创建了上下文对象Context
  • 3.在注释3处创建了Application对象,当然该对象只有一个,如果没有的话会创建,否则就直接返回一个已创建的Application
  • 4.在注释4处完成了Service的挂载操作,初始化了一些变量,如context等
  • 5.在注释5处完成了Service的onCreate方法的回调
    Service的onCreate方法的执行也就意味着Service已经被启动了,启动完成之后还要调用ActiveServcie的sendServiceArgsLocked方法来完成Service的onStartCommand方法的回调,该方法的代码实现如下:
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
            boolean oomAdjusted) {
        final int N = r.pendingStarts.size();
        if (N == 0) {
            return;
        }

        while (r.pendingStarts.size() > 0) {
            try {
                ServiceRecord.StartItem si = r.pendingStarts.remove(0);
                if (DEBUG_SERVICE) Slog.v(TAG, "Sending arguments to: "
                        + r + " " + r.intent + " args=" + si.intent);
                if (si.intent == null && N > 1) {
                    // If somehow we got a dummy null intent in the middle,
                    // then skip it.  DO NOT skip a null intent when it is
                    // the only one in the list -- this is to support the
                    // onStartCommand(null) case.
                    continue;
                }
                si.deliveredTime = SystemClock.uptimeMillis();
                r.deliveredStarts.add(si);
                si.deliveryCount++;
                if (si.neededGrants != null) {
                    mAm.grantUriPermissionUncheckedFromIntentLocked(si.neededGrants,
                            si.getUriPermissionsLocked());
                }
                bumpServiceExecutingLocked(r, execInFg, "start");
                if (!oomAdjusted) {
                    oomAdjusted = true;
                    mAm.updateOomAdjLocked(r.app);
                }
                int flags = 0;
                if (si.deliveryCount > 1) {
                    flags |= Service.START_FLAG_RETRY;
                }
                if (si.doneExecutingCount > 0) {
                    flags |= Service.START_FLAG_REDELIVERY;
                }
                //注释1
                r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
            } catch (RemoteException e) {
                // Remote process gone...  we'll let the normal cleanup take
                // care of this.
                if (DEBUG_SERVICE) Slog.v(TAG, "Crashed while scheduling start: " + r);
                break;
            } catch (Exception e) {
                Slog.w(TAG, "Unexpected exception", e);
                break;
            }
        }
    }

在注释1处会调用r.app.thread对象的scheduleServiceArgs方法,从此调用流程再次切换到ActivityThrad的内部类对象ApplicationThread的scheduleServiceArgs方法,下面我们看该方法的具体实现:

 public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
            int flags ,Intent args) {
            ServiceArgsData s = new ServiceArgsData();
            s.token = token;
            s.taskRemoved = taskRemoved;
            s.startId = startId;
            s.flags = flags;
            s.args = args;

            sendMessage(H.SERVICE_ARGS, s);
        }

其实不用贴代码我们也能猜到必然是发了一个消息,这和Service的onCreate方法的执行是一个套路,ActivityThread的消息处理器收到消息后会调用handleServiceArgs来完成onStartCommand的回调

private void handleServiceArgs(ServiceArgsData data) {
       Service s = mServices.get(data.token);
       if (s != null) {
           try {
               if (data.args != null) {
                   data.args.setExtrasClassLoader(s.getClassLoader());
                   data.args.prepareToEnterProcess();
               }
               int res;
               if (!data.taskRemoved) {
                   //注释1
                   res = s.onStartCommand(data.args, data.flags, data.startId);
               } else {
                   s.onTaskRemoved(data.args);
                   res = Service.START_TASK_REMOVED_COMPLETE;
               }

               QueuedWork.waitToFinish();

               try {
                   ActivityManagerNative.getDefault().serviceDoneExecuting(
                           data.token, 1, data.startId, res);
               } catch (RemoteException e) {
                   // nothing to do.
               }
               ensureJitEnabled();
           } catch (Exception e) {
               if (!mInstrumentation.onException(s, e)) {
                   throw new RuntimeException(
                           "Unable to start service " + s
                           + " with " + data.args + ": " + e.toString(), e);
               }
           }
       }
   }

在handleServiceArgs方法的注释1处我们清楚的看到了 s.onStartCommand,这时候Service的onStartCommand方法也被回调了,至此Service的启动流程就全部走完了。

总结

Service的启动流程的还是比较简单的,不像Activity那么复杂,相关联的类和方法都少了很多,不像Activity启动流程里面走着走着就会迷失方向,源码分析这是加强Android内功修炼的必修课,分析了几个流程之后,你就会觉得也不过如此,因为他们的套路都是一样的,大体的实现思想都相通的,只是具体的代码实现不同罢了。最后方便大家对Service启动的理解,我画了一张方法调用时序图,如下:


Android10.0 Service启动源码解析_第3张图片
在这里插入图片描述

Activity.startService
ContextWraper.startService
ContextImpl.startService
ContextImpl.startServiceCommon
ActivityManagerService.startService
ActiveService.startServiceLocked
ActiveService.startServiceInnerLocked
ActiveService.bringUpServiceLocked
ActiveService.realStartServiceLocked
ApplicationThread.scheduleCreateService
ActivityThread.handleCreateService
Service.onCreate
ActiveService.sendServiceArgsLocked
ApplicationThread.scheduleServiceArgs
ActivityThread.handleServiceArgs
Service.onStartCommand

问题反馈

在使用学习中有任何问题,请留言,或加入Android、Java开发技术交流群

Android10.0 Service启动源码解析_第4张图片
image

你可能感兴趣的:(Android10.0 Service启动源码解析)