Android源碼解析四大元件系列（一）---Service的啟動過程分析

這幾天分析了一下Activity的啟動過程和Service的啟動過程，于是乎，今天寫一下Service是如何啟動的。給我的感覺是這些啟動過程并不複雜，千萬不要被一坨一坨的代碼吓住了，雖然彎彎繞繞不少，重載函數一個接着一個，就向走迷宮一樣，但隻要抓住主線閱讀，很快就能找到出口。強調一下閱讀系統源碼，起碼要對程序間通信要了解，對binder機制非常非常清楚，binder就是指南針，要不然你會暈頭轉向。強行閱讀，就容易睡着。如果想看Binder的，移步Android源碼解析RPC系列(一)—Binder原理。

Service啟動先來一張圖感受一下

這張圖能夠說明一個大緻的流程，但是服務的啟動肯定不是這麼簡單，但是我們先簡單的總結一下，逐漸深入。服務的啟動形式有兩種，startService()和 binderService()，我們看startService()這一種。startService是ContextWrapper裡面的方法。

ContextWrapper.java

@Override
    public ComponentName startService(Intent service) {
        return mBase.startService(service);//mBase這裡指的是ContextImpl類
    }

ContextImpl.java

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

private ComponentName startServiceCommon(Intent service, UserHandle user) {
        try {
            //檢驗Intent
            validateServiceIntent(service);
             ......
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                            getContentResolver()), getOpPackageName(), user.getIdentifier());
             ......
            return cn;
        } catch (RemoteException e) {
            throw new RuntimeException("Failure from system", e);
        }
    }

校驗完Intent後，就調用ActivityManagerNative.getDefault()，擷取一個IActivityManager對象，将啟動Service這件事情交給了IActivityManager。我們看一下ActivityManagerNative的類定義

這種模式是不是非常熟悉啊？繼承了Binder，實作了一個IActivityManager接口，這個跟我們生成了遠端服務通信生成的AIDL的java檔案怎麼那麼像，現在告訴你，這就是為了遠端服務通信做準備的，隻是一般這種類我們都是自動生成的，ActivityManagerNative 是谷歌的人自己寫。一個完整的AID L有兩部分，一個是個跟服務端通信的Stub,一個是跟用戶端通信的Proxy。ActivityManagerNative就是Stub,閱讀源碼發現在ActivityManagerNative 檔案中還有個ActivityManagerProxy，那麼跟用戶端通信的Proxy也有了。先看IActivityManager怎麼擷取的。

ActivityManagerNative.java

static public IActivityManager getDefault() {
        return gDefault.get();
    }

private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
          //擷取名為"activity"的服務，服務都注冊到ServiceManager來統一管理
            IBinder b = ServiceManager.getService("activity");
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };

就是一個單例設計模式，擷取到服務對象IBinder，把這個IBinder轉換成IActivityManager傳回了。現在由IActivityManager啟動服務。

public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, String callingPackage, 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.writeString(callingPackage);
        data.writeInt(userId);

        mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);

        reply.readException();
        ComponentName res = ComponentName.readFromParcel(reply);
        data.recycle();
        reply.recycle();
        return res;
    }

上面說了ActivityManagerProxy作為binder通信的用戶端，ActivityManagerNative 作為binder通信的服務端。mRemote.transact()是binder通信的用戶端發起方法，經過binder驅動，最後回到binder服務端ActivityManagerNative的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();
                        String callingPackage = data.readString();
                        int userId = data.readInt();
                        ComponentName cn = startService(app, service, resolvedType, callingPackage, userId);
                        reply.writeNoException();
                        ComponentName.writeToParcel(cn, reply);
                        return true;
                    }
        }
        .......
    }

ActivityManagerNative的真正實作是ActivityManagerService，是以binder通信的服務端的ActivityManagerService，ActivityManagerProxy.startService()最終調用ActivityManagerService.startService()。注意這就跨程序了，ActivityManagerService是一個服務端的程序。看ActivityManagerService中的startService方法。

ActivityManagerService.java

public ComponentName startService(IApplicationThread caller, Intent service,
            String resolvedType, String callingPackage, int userId)
            throws TransactionTooLargeException {
        ......
        synchronized(this) {
            .......
            ComponentName res = mServices.startServiceLocked(caller, service,
                    resolvedType, callingPid, callingUid, callingPackage, userId);
            Binder.restoreCallingIdentity(origId);
            return res;
        }
    }

ActivityManagerService沒有直接幹這個活，而是把這個任務交給了mService, mService 是一個 ActiveServices 對象。在早期的安卓版本中并沒有這個類，後來重構時抽出這個類專門用來管理Service.

ActiveServices.java

ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
            int callingPid, int callingUid, String callingPackage, int userId)
            throws TransactionTooLargeException {
              ........
              return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }

startServiceInnerLocked調用了 bringUpServiceLocked(),bringUpServiceLocked()内部調用了realStartServiceLocked()，我們看realStartServiceLocked()方法。

private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
       .......
        try {
            .......
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            r.postNotification();
            created = true;
        } catch (DeadObjectException e) {
            ....
        } finally {
           ....
        }

        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() == ) {
            r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                    null, null));
        }
       // 進入onStartCommand()
        sendServiceArgsLocked(r, execInFg, true);

       ....
    }

這裡的關鍵是

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

app 是要運作 Service 的程序對應的 ProcessRecord 對象，代表一個應用程序。要區分一下，一般我們都是單方向通信，用戶端将處理請求發送給服務端，服務端處理後傳回，如果要服務端向用戶端發送一個“請求”呢？這裡的thread 是一個 ApplicationThreadProxy 對象，它是應用程序的 ApplicatonThread 對象在 AMS 端的代理，AMS 靠它來和應用程序進行通信。是以AMS和應用程序可以雙向通信了。

Android源碼解析四大元件系列（一）---Service的啟動過程分析

ApplicationThreadProxy.java

public final void scheduleCreateService(IBinder token, ServiceInfo info,
        CompatibilityInfo compatInfo, int processState) throws RemoteException {
    Parcel data = Parcel.obtain();
    data.writeInterfaceToken(IApplicationThread.descriptor);
    data.writeStrongBinder(token);
    info.writeToParcel(data, 0);
    compatInfo.writeToParcel(data, 0);
    data.writeInt(processState);
    try {
        mRemote.transact(SCHEDULE_CREATE_SERVICE_TRANSACTION, data, null, IBinder.FLAG_ONEWAY);
    } catch (TransactionTooLargeException e) {
        throw e;
    }
    data.recycle();
}

執行mRemote.transact後，就會回調ApplicationThreadNative的onTransact,這是Binder的套路。

ApplicationThreadNative.java

public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
        throws RemoteException {
    switch (code) {
    case SCHEDULE_CREATE_SERVICE_TRANSACTION: {
        data.enforceInterface(IApplicationThread.descriptor);
        IBinder token = data.readStrongBinder();
        ServiceInfo info = ServiceInfo.CREATOR.createFromParcel(data);
        CompatibilityInfo compatInfo = CompatibilityInfo.CREATOR.createFromParcel(data);
        int processState = data.readInt();
        scheduleCreateService(token, info, compatInfo, processState);
        return true;
    }
    ...
}

内部調用scheduleCreateService，看上面的圖，可以知道，scheduleCreateService是屬于ApplicatonThread的。

ApplicatonThread.java

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

發送一個消息，這個消息都是由H類處理的，H類就是系統Hander,專門處理系統請求的，比如一些Activity的生命周期等全在這裡面。這個 H對象是在應用程序的主線程中建立的，是以最終的結果是把建立 Service 的消息傳到了主線程,是以Service是運作在主線程中的。

H.java

private class H extends Handler {
          .........
            public void handleMessage(Message msg) {

            if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
            switch (msg.what) {

             case CREATE_SERVICE:
                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceCreate");
                    handleCreateService((CreateServiceData)msg.obj);
                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            }
        }

ActivityThread.java

private void handleCreateService(CreateServiceData data) {

        .......
        LoadedApk packageInfo = getPackageInfoNoCheck(
                data.info.applicationInfo, data.compatInfo);
        Service service = null;
        try {
            // 反射加載Service
            java.lang.ClassLoader cl = packageInfo.getClassLoader();
            service = (Service) cl.loadClass(data.info.name).newInstance();
        } catch (Exception e) {
            .......
        }

        try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
             //建立ContextImpl對象
            ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
            context.setOuterContext(service);
             //建立Application對象
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManagerNative.getDefault());
            //回調onCreate方法
            service.onCreate();
            mServices.put(data.token, service);
            try {
              //調用服務建立完成
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_ANON, , );
            } catch (RemoteException e) {
                // nothing to do.
            }
        } catch (Exception e) {
           .......
        }
    }

到此Service的onCreate就回調了，那麼onStartCommand()何時回調呢？在realStartServiceLocked中調用了sendServiceArgsLocked(r, execInFg, true),sendServiceArgsLocked與上面類似，最終也是發送了一個（SERVICE_ARGS）消息。

ApplicationThread.java

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

ActivityThread.java

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) {
                //onStartCommand回調
                    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, SERVICE_DONE_EXECUTING_START, data.startId, res);
                } catch (RemoteException e) {
                    // nothing to do.
                }
                ensureJitEnabled();
            } catch (Exception e) {
               ......
            }
        }
    }

Service的onCreate的回調和onStartCommand的回調套路是完全一樣的，朋友們可以自己體會，onCreate的回調先執行scheduleCreateService()方法，最終回調Service.onCreate(); onStartCommand的回調先執行scheduleServiceArgs()方法，最終回調Service.onStartCommand()。

總結一下：

IActivityManager接口中定義了AMS向應用程式（本例中即Activity）提供的多種API，Activity通過ActivityManagerProxy就可以使用這些API，向AMS送出請求，是以是通過ActivityManagerProxy，調用ActivityManagerProxy的startService方法，在内部調用transact，然後會調用ActivityManagerNative中的onTransact()方法，在該方法中，将會r完成AMS與Activity的連接配接并調用AMS的startService()方法，那麼AMS是如何Service所在的應用程式呢？比如scheduleCreateService。原來ApplicationThreadProxy 是應用程序的 ApplicatonThread 對象在 AMS 端的代理，AMS 靠它來和應用程序進行通信。這就是Activity與AMS之間的雙向Binder連接配接。Activity用IActivityManager提供的APIActivityManagerService提出執行某個動作的請求（本例中是啟動RemoteService），ActivityManagerService通過IApplicationThread提供的API來控制Activity所在的應用程式。

上面的分析省去了很多的内容，如果從程序角度看服務啟動過程。

Process A程序：是指調用startService指令所在的程序，也就是啟動服務的發起端程序。

system_server程序：系統程序，是java framework架構的核心載體，裡面運作了大量的系統服務，比如這裡提供ApplicationThreadProxy，ActivityManagerService，這個兩個服務都運作在system_server程序的不同線程中。

Zygote程序：是由init程序孵化而來的，用于建立Java層程序的母體，所有的Java層程序都是由Zygote程序孵化而來；

Remote Service程序：遠端服務所在程序，是由Zygote程序孵化而來的用于運作Remote服務的程序。主線程主要負責Activity/Service等元件的生命周期以及UI相關操作都運作在這個線程；另外，每個App程序中至少會有兩個binder線程 ApplicationThread和ActivityManagerProxy

Android源碼解析四大元件系列（一）---Service的啟動過程分析

啟動流程：

Process A程序采用Binder IPC向system_server程序發起startService請求；
system_server程序接收到請求後，向zygote程序發送建立程序的請求；
zygote程序fork出新的子程序Remote Service程序；
Remote Service程序，通過Binder IPC向sytem_server程序發起attachApplication請求；
system_server程序在收到請求後，進行一系列準備工作後，再通過binder IPC向remote Service程序發送scheduleCreateService請求；
Remote Service程序的binder線程在收到請求後，通過handler向主線程發送CREATE_SERVICE消息；
主線程在收到Message後，通過發射機制建立目标Service，并回調Service.onCreate()方法。

到此，服務便正式啟動完成。當建立的是本地服務或者服務所屬程序已建立時，則無需經過上述步驟2、3，直接建立服務即可

參考：http://www.itdadao.com/articles/c15a1052268p0.html

http://gityuan.com/2016/03/06/start-service/

Please accept mybest wishes for your happiness and success !

Android源碼解析四大元件系列（一）---Service的啟動過程分析

繼續閱讀

與專家面對面：Android開發入門問與答

Android MVP架構MVCMVP

mvp初探

Android常用工具類簡介目錄

android常用工具類轉載自：http://www.trinea.cn/android/android-common-utils/Android常用工具類

Android常用工具類ToastUtilsSizeUtilsLogUtilsRetrofitManagerAnimUtil

Android Studio 0.8.0解決 Failure [INSTALL_FAILED_OLDER_SDK] 問題

sshd dead but subsys locked問題解決

Android – ListView 中添加按鈕，動态删除添加ItemView的操作

Kotlin的ListView與RecyclerView的簡單應用

關于公司的那些坑：Android Studio篇

android SQLite事務和kotlin協程

無法正常編譯錯誤Compilation failed to complete

關于Gradle配置的小結

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

Android APK檔案反編譯Android APK檔案反編譯