【Android源码系列】Service启动源码解析

一、写在前面

上次说了Activity启动，我们接着来看Service。同为四大组件，两者的启动方式相差不多，有了上次的经验，分析起来得心应手。但是我们知道Service有两种方式：start&bind。

Intent intent = new Intent(MainActivity.this, StartService.class);                startService(intent);                bindService(intent,serviceConnection,BIND_AUTO_CREATE);

上面的代码想必大家很熟悉了，废话不多说，进入正题。

二、startService方式

直接进入startService方法，我们看到：

    public ComponentName startService(Intent service) {        return mBase.startService(service);    }

是在contextWraper里面，并交给了mBase去执行。往上查找，发现这个mBase是Activity启动时attach方法里生成并传入的。

ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);

发现他是一个ContextImpl对象，继承了context而已。我继续看他的startService方法，发现他调用了自己的startServiceCommon。在startServiceCommon里面我们看到了一行熟悉的代码：

private ComponentName startServiceCommon(Intent service, UserHandle user) {        try {            validateServiceIntent(service);            service.prepareToLeaveProcess();            ComponentName cn = ActivityManagerNative.getDefault().startService(                mMainThread.getApplicationThread(), service,                service.resolveTypeIfNeeded(getContentResolver()), user.getIdentifier());            //省略部分代码            return cn;        } catch (RemoteException e) {            return null;        }    }

这里和Activity启动方式相同，都是通过binder对象进行进程通信，这里我就不多说了，还不清楚的可以先看我的上一篇文章。这里我们直接找到ActivityManegerService（简称AMS）里的startService方法。

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();            ComponentName res = mServices.startServiceLocked(caller, service,                    resolvedType, callingPid, callingUid, userId);            Binder.restoreCallingIdentity(origId);            return res;        }

这个方法也很简单，发现他直接交给mServices处理了，这个mServices是一个ActiveServices的实例，这个类负责Service的很多工作，具体可以下来详细看，这里先不多说。

我们进入到ActiveServices这个类里，发现先调用了startServiceLocked，再调用startServiceInnerLocked，然后继续走到bringUpServiceLocked，最后进入了realStartServiceLocked方法，看名字感觉是真正启动Service的地方了

private final void realStartServiceLocked(ServiceRecord r,            ProcessRecord app, boolean execInFg) throws RemoteException {        try {            if (LOG_SERVICE_START_STOP) {                String nameTerm;                int lastPeriod = r.shortName.lastIndexOf('.');                nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;                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);            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));        }        sendServiceArgsLocked(r, execInFg, true);        if (r.delayed) {            if (DEBUG_DELAYED_STARTS) Slog.v(TAG, "REM FR DELAY LIST (new proc): " + r);            getServiceMap(r.userId).mDelayedStartList.remove(r);            r.delayed = false;        }        if (r.delayedStop) {            // Oh and hey we've already been asked to stop!            r.delayedStop = false;            if (r.startRequested) {                if (DEBUG_DELAYED_STARTS) Slog.v(TAG, "Applying delayed stop (from start): " + r);                stopServiceLocked(r);            }        }    }

这个方法很重要，后面我们还需要回头看，这里先分析Service的启动：

 app.thread.scheduleCreateService(r, r.serviceInfo,                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),                    app.repProcState);

这句是不是很熟悉，和Activity的启动如出一辙，其实Service启动本来就和Activity相差不大。同样的，我们找到ActivityThread里的scheduleCreateService，同样的，还是通过H这个Handler调用了方法handleCreateService。在这个方法里调用了attach和onCreate，我们的Service正式启动了。

service.attach(context, this, data.info.name, data.token, app,                    ActivityManagerNative.getDefault());            service.onCreate();

不过很奇怪的是，我找了很久，往下再也没有出现Onstart之类的生命周期。无奈，只能回头看看，终于在刚刚提到的realStartServiceLocked方法了看到了

       // 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));        }        sendServiceArgsLocked(r, execInFg, true);

看注释大概意思是“这里如果启动过了，将不再调用onStartCommand，如果没有则调用”，所以进去sendServiceArgsLocked方法里瞧瞧，同样的，我们找到了和onCreate启动相同的方式。

 r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);

通过binder跨进程调用了onStartCommand方法，后续原理相同我就不一一贴代码了。这里就把startService启动方式分析完了，发现和Activity启动方式本质上没什么差别，那bind方式呢？

三、bind启动方式

一路查看bind启动的源码，发现TMD和start方式一毛一样，最后都走到了ActiveServices的realStartServiceLocked方法里，执行一遍onCreate。只是不会执行onStartCommand，而是执行了requestServiceBindingsLocked(r, execInFg)方法，同样的，也是跨进程调用了ActivityThread里的方法：

r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,                        r.app.repProcState);

然后走到handleBindService方法里：

 try {                    if (!data.rebind) {                        IBinder binder = s.onBind(data.intent);                        ActivityManagerNative.getDefault().publishService(                                data.token, data.intent, binder);                    } else {                        s.onRebind(data.intent);                        ActivityManagerNative.getDefault().serviceDoneExecuting(                                data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);                    }                    ensureJitEnabled();                } catch (RemoteException ex) {                }

可以看出，onbind方法之会调用一次。
那这样就完了吗？不对呀，bind启动还需要一个东西，ServiceConnection！通过onServiceConnected方法来获取Service传过来的binder对象。好吧，继续看。
我们看到onbind调用之后还会继续调用下面这句话：

ActivityManagerNative.getDefault().publishService(                                data.token, data.intent, binder);

很熟悉的binder通信，我们直接跳到AMS的publishService方法，经过一番辗转，我们看到了这句话：

 void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {        //省略无数代码        try {            try {                c.conn.connected(r.name, service);                            } catch (Exception e) {                            }                        }                    }                }            }        } finally {            Binder.restoreCallingIdentity(origId);        }    }

这里调用了conn的connected，好像离成功很近了。我们发现conn是一个IServiceConnection接口，又是一次IPC通信。那我们看看这个c是哪里来的。往上跟踪代码最后找到了ContextImpl里的bindServiceCommon

private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,            UserHandle user) {        IServiceConnection sd;        if (conn == null) {            throw new IllegalArgumentException("connection is null");        }        if (mPackageInfo != null) {            sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),                    mMainThread.getHandler(), flags);        } else {            throw new RuntimeException("Not supported in system context");        }        validateServiceIntent(service);        try {            IBinder token = getActivityToken();            if (token == null && (flags&BIND_AUTO_CREATE) == 0 && mPackageInfo != null                    && mPackageInfo.getApplicationInfo().targetSdkVersion                    < android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {                flags |= BIND_WAIVE_PRIORITY;            }            service.prepareToLeaveProcess();            int res = ActivityManagerNative.getDefault().bindService(                mMainThread.getApplicationThread(), getActivityToken(),                service, service.resolveTypeIfNeeded(getContentResolver()),                sd, flags, user.getIdentifier());            if (res < 0) {                throw new SecurityException(                        "Not allowed to bind to service " + service);            }            return res != 0;        } catch (RemoteException e) {            return false;        }    }

IServiceConnection 对象sd是通过getServiceDispatcher方法得到，继续跟进发现是一个LoadedApk的内部类ServiceDispatcher的内部类InnerConnection （有点绕），继承了IServiceConnection.Stub

        private static class InnerConnection extends IServiceConnection.Stub {            final WeakReference<LoadedApk.ServiceDispatcher> mDispatcher;            InnerConnection(LoadedApk.ServiceDispatcher sd) {                mDispatcher = new WeakReference<LoadedApk.ServiceDispatcher>(sd);            }            public void connected(ComponentName name, IBinder service) throws RemoteException {                LoadedApk.ServiceDispatcher sd = mDispatcher.get();                if (sd != null) {                    sd.connected(name, service);                }            }        }

可以看到，还是调用了sd的connected方法：

public void connected(ComponentName name, IBinder service) {            if (mActivityThread != null) {                mActivityThread.post(new RunConnection(name, service, 0));            } else {                doConnected(name, service);            }        }

mActivityThread其实就是一个Handler对象，往上翻他其实就H，执行了一个runable，runable里面同样走到了doConnected里，我们来看看这个doConnected

public void doConnected(ComponentName name, IBinder service) {            ServiceDispatcher.ConnectionInfo old;            ServiceDispatcher.ConnectionInfo info;            synchronized (this) {                if (mForgotten) {                    // We unbound before receiving the connection; ignore                    // any connection received.                    return;                }                old = mActiveConnections.get(name);                if (old != null && old.binder == service) {                    // Huh, already have this one.  Oh well!                    return;                }                if (service != null) {                    // A new service is being connected... set it all up.                    mDied = false;                    info = new ConnectionInfo();                    info.binder = service;                    info.deathMonitor = new DeathMonitor(name, service);                    try {                        service.linkToDeath(info.deathMonitor, 0);                        mActiveConnections.put(name, info);                    } catch (RemoteException e) {                        // This service was dead before we got it...  just                        // don't do anything with it.                        mActiveConnections.remove(name);                        return;                    }                } else {                    // The named service is being disconnected... clean up.                    mActiveConnections.remove(name);                }                if (old != null) {                    old.binder.unlinkToDeath(old.deathMonitor, 0);                }            }            // If there was an old service, it is not disconnected.            if (old != null) {                mConnection.onServiceDisconnected(name);            }            // If there is a new service, it is now connected.            if (service != null) {                mConnection.onServiceConnected(name, service);            }        }

很轻松的发现里面确实调用了

mConnection.onServiceConnected(name, service);

至此，bind绑定完成。

四、总结

可以发现，无论是start方式还是bind方式，甚至包括Activity启动方式，核心都是通过IPC通信完成的，可见binder在Android里的地位。
那是因为无论是Activity还是Service都涉及到了跨进程启动，比如从你的应用跳转到别的应用，包括跳到Home页面（其实Home界面也是一个进程）。
好的，下一篇将继续分析四大组件，让我们来看看Android这四大组件的原理，这会让我们对Android系统有更加深刻的认识。
最后还是老样子，画出UML图将对整个步骤更加清晰。