【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图将对整个步骤更加清晰。