當前位置：首頁 > 运维知识 > Android >内容正文

Android

Android 插件化原理解析——Service的插件化

發布時間：2025/3/15 Android 16 豆豆

生活随笔收集整理的這篇文章主要介紹了 Android 插件化原理解析——Service的插件化小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

在?Activity生命周期管理?以及?廣播的管理?中我們詳細探討了Android系統中的Activity、BroadcastReceiver組件的工作原理以及它們的插件化方案，相信讀者已經對Android Framework和插件化技術有了一定的了解；本文將探討Android四大組件之一——Service組件的插件化方式。

與Activity, BroadcastReceiver相比，Service組件的不同點在哪里呢？我們能否用與之相同的方式實現Service的插件化？如果不行，它們的差別在哪里，應該如何實現Service的插件化？

我們接下來將圍繞這幾個問題展開，最終給出Service組件的插件化方式；閱讀本文之前，可以先clone一份?understand-plugin-framework，參考此項目的 service-management 模塊。另外，插件框架原理解析系列文章見索引。

Service工作原理

連Service的工作原理都不了解，談何插件化？知己知彼。

Service分為兩種形式：以startService啟動的服務和用bindService綁定的服務；由于這兩個過程大體相似，這里以稍復雜的bindService為例分析Service組件的工作原理。

綁定Service的過程是通過Context類的bindService完成的，這個方法需要三個參數：第一個參數代表想要綁定的Service的Intent，第二個參數是一個ServiceConnetion，我們可以通過這個對象接收到Service綁定成功或者失敗的回調；第三個參數則是綁定時候的一些FLAG；關于服務的基本概念，可以參閱?官方文檔。（現在漢化了哦，E文不好童鞋的福音）

Context的具體實現在ContextImpl類，ContextImpl中的bindService方法直接調用了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) {
        // important
        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, getOpPackageName(), user.getIdentifier());
        if (res < 0) {
            throw new SecurityException(
                    "Not allowed to bind to service " + service);
        }
        return res != 0;
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
}
 

大致觀察就能發現這個方法最終通過ActivityManagerNative借助AMS進而完成Service的綁定過程，在跟蹤AMS的bindService源碼之前，我們關注一下這個方法開始處創建的sd變量。這個變量的類型是IServiceConnection，如果讀者還有印象，我們在?廣播的管理?一文中也遇到過類似的處理方式——IIntentReceiver；所以，這個IServiceConnection與IApplicationThread以及IIntentReceiver相同，都是ActivityThread給AMS提供的用來與之進行通信的Binder對象；這個接口的實現類為LoadedApk.ServiceDispatcher。

這個方法最終調用了ActivityManagerNative的bindService，而這個方法的真正實現在AMS里面，源碼如下：

 public int bindService(IApplicationThread caller, IBinder token, Intent service,
        String resolvedType, IServiceConnection connection, int flags, String callingPackage,
        int userId) throws TransactionTooLargeException {
    enforceNotIsolatedCaller("bindService");
    // 略去參數校檢
    synchronized(this) {
        return mServices.bindServiceLocked(caller, token, service,
                resolvedType, connection, flags, callingPackage, userId);
    }
}
 

bindService這個方法相當簡單，只是做了一些參數校檢之后直接調用了ActivityServices類的bindServiceLocked方法：

 int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
        String resolvedType, IServiceConnection connection, int flags,
        String callingPackage, int userId) throws TransactionTooLargeException {
    final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
    // 參數校檢，略

    ServiceLookupResult res =
        retrieveServiceLocked(service, resolvedType, callingPackage,
                Binder.getCallingPid(), Binder.getCallingUid(), userId, true, callerFg);
    // 結果校檢， 略
    ServiceRecord s = res.record;

    final long origId = Binder.clearCallingIdentity();

    try {
        // ... 不關心， 略

        mAm.startAssociationLocked(callerApp.uid, callerApp.processName,
                s.appInfo.uid, s.name, s.processName);

        AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
        ConnectionRecord c = new ConnectionRecord(b, activity,
                connection, flags, clientLabel, clientIntent);
        IBinder binder = connection.asBinder();
        ArrayList<ConnectionRecord> clist = s.connections.get(binder);

        // 對connection進行處理， 方便存取，略
        clist.add(c);

        if ((flags&Context.BIND_AUTO_CREATE) != 0) {
            s.lastActivity = SystemClock.uptimeMillis();
            if (bringUpServiceLocked(s, service.getFlags(), callerFg, false) != null) {
                return 0;
            }
        }

        // 與BIND_AUTO_CREATE不同的啟動FLAG，原理與后續相同，略

    } finally {
        Binder.restoreCallingIdentity(origId);
    }

    return 1;
}
 

這個方法比較長，我這里省去了很多無關代碼，只列出關鍵邏輯；首先它通過retrieveServiceLocked方法獲取到了intent匹配到的需要bind到的Service組件res；然后把ActivityThread傳遞過來的IServiceConnection使用ConnectionRecord進行了包裝，方便接下來使用；最后如果啟動的FLAG為BIND_AUTO_CREATE，那么調用bringUpServiceLocked開始創建Service，我們跟蹤這個方法：（非這種FLAG的代碼已經省略，可以自行跟蹤）

 private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
        boolean whileRestarting) throws TransactionTooLargeException {
  
    // 略。。

    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 (app != null && app.thread != null) {
            try {
                app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                // 1. important !!!
                realStartServiceLocked(r, app, execInFg);
                return null;
            } catch (TransactionTooLargeException e) {
                throw e;
            } catch (RemoteException e) {
                Slog.w(TAG, "Exception when starting service " + r.shortName, e);
            }

        }
    } else {
        app = r.isolatedProc;
    }

    // Not running -- get it started, and enqueue this service record
    // to be executed when the app comes up.
    if (app == null) {
        // 2. important !!!
        if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                "service", r.name, false, isolated, false)) == null) {
            bringDownServiceLocked(r);
            return msg;
        }
        if (isolated) {
            r.isolatedProc = app;
        }
    }
    // 略。。
    return null;
}
 

這個方案同樣也很長，但是實際上非常簡單：注意我注釋的兩個important的地方，如果Service所在的進程已經啟動，那么直接調用realStartServiceLocked方法來真正啟動Service組件；如果Service所在的進程還沒有啟動，那么先在AMS中記下這個要啟動的Service組件，然后通過startProcessLocked啟動新的進程。

我們先看Service進程已經啟動的情況，也即realStartServiceLocked分支：

 private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {
    
    // 略。。

    boolean created = false;
    try {
        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) {
        mAm.appDiedLocked(app);
        throw e;
    } finally {
        // 略。。
    }

    requestServiceBindingsLocked(r, execInFg);

    // 不關心，略。。
}
 

這個方法首先調用了app.thread的scheduleCreateService方法，我們知道，這是一個IApplicationThread對象，它是App所在進程提供給AMS的用來與App進程進行通信的Binder對象，這個Binder的Server端在ActivityThread的ApplicationThread類，因此，我們跟蹤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);
}
 

它不過是轉發了一個消息給ActivityThread的H這個Handler，H類收到這個消息之后，直接調用了ActivityThread類的handleCreateService方法，如下：

 private void handleCreateService(CreateServiceData data) {
    unscheduleGcIdler();

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

    try {
        ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
        context.setOuterContext(service);

        Application app = packageInfo.makeApplication(false, mInstrumentation);
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManagerNative.getDefault());
        service.onCreate();
        mServices.put(data.token, service);
        try {
            ActivityManagerNative.getDefault().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            // nothing to do.
        }
    } catch (Exception e) {
    }
}
 

看到這段代碼，是不是似曾相識？！沒錯，這里與Activity組件的創建過程如出一轍！所以這里就不贅述了，可以參閱?Activity生命周期管理。

需要注意的是，這里Service類的創建過程與Activity是略微有點不同的，雖然都是通過ClassLoader通過反射創建，但是Activity卻把創建過程委托給了Instrumentation類，而Service則是直接進行。

OK，現在ActivityThread里面的handleCreateService方法成功創建出了Service對象，并且調用了它的onCreate方法；到這里我們的Service已經啟動成功。scheduleCreateService這個Binder調用過程結束，代碼又回到了AMS進程的realStartServiceLocked方法。這里我們不得不感嘆Binder機制的精妙，如此簡潔方便高效的跨進程調用，在進程之間來回穿梭，游刃有余。

realStartServiceLocked方法的代碼如下：

 private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {
    
    // 略。。

    boolean created = false;
    try {
        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) {
        mAm.appDiedLocked(app);
        throw e;
    } finally {
        // 略。。
    }

    requestServiceBindingsLocked(r, execInFg);

    // 不關心，略。。
}
 

這個方法在完成scheduleCreateService這個binder調用之后，執行了一個requestServiceBindingsLocked方法；看方法名好像于「綁定服務」有關，它簡單地執行了一個遍歷然后調用了另外一個方法：

 private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
        boolean execInFg, boolean rebind) throws TransactionTooLargeException {
    if (r.app == null || r.app.thread == null) {
        return false;
    }
    if ((!i.requested || rebind) && i.apps.size() > 0) {
        try {
            bumpServiceExecutingLocked(r, execInFg, "bind");
            r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
                    r.app.repProcState);
        // 不關心，略。。
    }
    return true;
}
 

可以看到，這里又通過IApplicationThread這個Binder進行了一次IPC調用，我們跟蹤ActivityThread類里面的ApplicationThread的scheduleBindService方法，發現這個方法不過通過Handler轉發了一次消息，真正的處理代碼在handleBindService里面：

 private void handleBindService(BindServiceData data) {
    Service s = mServices.get(data.token);
    if (s != null) {
        try {
            data.intent.setExtrasClassLoader(s.getClassLoader());
            data.intent.prepareToEnterProcess();
            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) {
            }
        } catch (Exception e) {
        }
    }
}
 

我們要Bind的Service終于在這里完成了綁定！綁定之后又通過ActivityManagerNative這個Binder進行一次IPC調用，我們查看AMS的publishService方法，這個方法簡單第調用了publishServiceLocked方法，源碼如下：

 void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
    final long origId = Binder.clearCallingIdentity();
    try {
        if (r != null) {
            Intent.FilterComparison filter
                    = new Intent.FilterComparison(intent);
            IntentBindRecord b = r.bindings.get(filter);
            if (b != null && !b.received) {
                b.binder = service;
                b.requested = true;
                b.received = true;
                for (int conni=r.connections.size()-1; conni>=0; conni--) {
                    ArrayList<ConnectionRecord> clist = r.connections.valueAt(conni);
                    for (int i=0; i<clist.size(); i++) {
                        ConnectionRecord c = clist.get(i);
                        if (!filter.equals(c.binding.intent.intent)) {
                            continue;
                        }
                        try {
                            c.conn.connected(r.name, service);
                        } catch (Exception e) {
                        }
                    }
                }
            }

            serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
        }
    } finally {
        Binder.restoreCallingIdentity(origId);
    }
}
 

還記得我們之前提到的那個IServiceConnection嗎？在bindServiceLocked方法里面，我們把這個IServiceConnection放到了一個ConnectionRecord的List中存放在ServiceRecord里面，這里所做的就是取出已經被Bind的這個Service對應的IServiceConnection對象，然后調用它的connected方法；我們說過，這個IServiceConnection也是一個Binder對象，它的Server端在LoadedApk.ServiceDispatcher里面。代碼到這里已經很明確了，由于分析過程過長，再繼續估計大家要瞌睡了；接下來的過程非常簡單，感興趣的讀者自行查閱LoadedApk.ServiceDispatcher的connected方法，一路跟蹤弄清楚ServiceConnection回調過程，完成最后的拼圖！

最后提一點，以上我們分析了Service所在進程已經存在的情況，如果Service所在進程不存在，那么會調用startProcessLocked方法創建一個新的進程，并把需要啟動的Service放在一個隊列里面；創建進程的過程通過Zygote fork出來，進程創建成功之后會調用ActivityThread的main方法，在這個main方法里面間接調用到了AMS的attachApplication方法，在AMS的attachApplication里面會檢查剛剛那個待啟動Service隊列里面的內容，并執行Service的啟動操作；之后的啟動過程與進程已經存在的情況下相同；可以自行分析。

Service的插件化思路

現在我們已經明白了Service組件的工作原理，可對如何實現Service的插件化依然是一頭霧水。

從上文的源碼分析來看，Service組件與Activity有著非常多的相似之處：它們都是通過Context類完成啟動，接著通過ActivityMnagaerNative進入AMS，最后又通過IApplicationThread這個Binder IPC到App進程的Binder線程池，然后通過H轉發消息到App進程的主線程，最終完成組件生命周期的回調；對于Service組件，看起來好像可以沿用Activity組件的插件化方式：Hook掉ActivityManagerNative以及H類，但事實真的如此嗎？

Service與Activity的異同

Service組件和Activity組件有什么不同？這些不同使得我們對于插件化方案的選擇又有什么影響？

用戶交互對于生命周期的影響

首先，Activity與Service組件最大的不同點在于，Activity組件可以與用戶進行交互；這一點意味著用戶的行為會對Activity組件產生影響，對我們來說最重要的影響就是Activity組件的生命周期；用戶點擊按鈕從界面A跳轉到界面B，會引起A和B這兩個Activity一系列生命周期的變化。而Service組件則代表后臺任務，除了內存不足系統回收之外，它的生命周期完全由我們的代碼控制，與用戶的交互無關。

這意味著什么？

Activity組件的生命周期受用戶交互影響，而這種變化只有Android系統才能感知，因此我們必須把插件的Activity交給系統管理，才能擁有完整的生命周期；但Service組件的生命周期不受外界因素影響，那么自然而然，我們可以手動控制它的生命周期，就像我們對于BroadcastReceiver的插件化方式一樣！Activity組件的插件化無疑是比較復雜的，為了把插件Activity交給系統管理進而擁有完整生命周期，我們設計了一個天衣無縫的方案騙過了AMS；既然Service的生命周期可以由我們自己控制，那么我們可以有更簡單的方案實現它的插件化。

Activity的任務棧

上文指出了Activity和Service組件在處理用戶交互方面的不同，這使得我們對于Service組建的插件化可以選擇一種較為簡單的方式；也許你會問，那采用Activity插件化的那一套技術能夠實現Service組件的插件化嗎？

很遺憾，答案是不行的。雖然Activity的插件化技術更復雜，但是這種方案并不能完成Service組件的插件化——復雜的方案并不意味了它能處理更多的問題。

原因在于Activity擁有任務棧的概念。或許你覺得任務棧并不是什么了不起的東西，但是，這確實是Service組件與Activity組件插件化方式分道揚鑣的根本原因。

任務棧的概念使得Activtiy的創建就代表著入棧，銷毀則代表出棧；又由于Activity代表著與用戶交互的界面，所以這個棧的深度不可能太深——Activity棧太深意味著用戶需要狂點back鍵才能回到初始界面，這種體驗顯然有問題；因此，插件框架要處理的Activity數量其實是有限的，所以我們在AndroidManifest.xml中聲明有限個StubActivity就能滿足插件啟動近乎無限個插件Activity的需求。

但是Service組件不一樣，理論情況下，可以啟動的Service組件是無限的——除了硬件以及內存資源，沒有什么限制它的數目；如果采用Activity的插件化方式，就算我們在AndroidMafenist.xml中聲明再多的StubService，總有不能滿足插件中要啟動的Service數目的情況出現。也許有童鞋會說，可以用一個StubService對應多個插件Service，這確實能解決部分問題；但是，下面的這個區別讓這種設想徹底泡湯。

Service無法擁有多實例

Service組件與Activity組件另外一個不同點在于，對同一個Service調用多次startService并不會啟動多個Service實例，而非特定Flag的Activity是可以允許這種情況存在的，因此如果用StubService的方式，為了實現Service的這種特性，必須建立一個StubService到插件Service的一個Map，Map的這種一一對應關系使得我們使用一個StubService對應多個插件Service的計劃成為天方夜譚。

至此，結論已經非常清晰——對于Service組件的插件化，我們不能簡單地套用Activity的方案。

如何實現Service的插件化？

上文指出，我們不能套用Activity的方案實現Service組件的插件化，可以通過手動控制Service組件的生命周期實現；我們先來看一下Service的生命周期：

Service生命周期

從圖中可以看出，Service的生命周期相當簡單：整個生命周期從調用 onCreate() 開始起，到 onDestroy() 返回時結束。對于非綁定服務，就是從startService調用到stopService或者stopSelf調用。對于綁定服務，就是bindService調用到unbindService調用；

如果要手動控制Service組件的生命周期，我們只需要模擬出這個過程即可；而實現這一點并不復雜：

如果以startService方式啟動插件Service，直接回調要啟動的Service對象的onStartCommand方法即可；如果用stopService或者stopSelf的方式停止Service，只需要回調對應的Service組件的onDestroy方法。

如果用bindService方式綁定插件Service，可以調用對應Service對應的onBind方法，獲取onBind方法返回的Binder對象，然后通過ServiceConnection對象進行回調統計；unBindService的實現同理。

完全手動控制

現在我們已經有了實現思路，那么具體如何實現呢？

我們必須在startService,stopService等方法被調用的時候拿到控制權，才能手動去控制Service的生命周期；要達到這一目的非常簡單——Hook ActivityManagerNative即可。在Activity的插件化方案中我們就通過這種方式接管了startActivity調用，相信讀者并不陌生。

我們Hook掉ActivityManagerNative之后，可以攔截對于startService以及stopService等方法的調用；攔截之后，我們可以直接對插件Service進行操作：

攔截到startService之后，如果Service還沒有創建就直接創建Service對象（可能需要加載插件），然后調用這個Service的onCreate,onStartCommond方法；如果Service已經創建，獲取到原來創建的Service對象并執行其onStartCommand方法。

攔截到stopService之后，獲取到對應的Service對象，直接調用這個Service的onDestroy方法。

這種方案簡直簡單得讓人不敢相信！很可惜，這么干是不行的。

首先，Service存在的意義在于它作為一個后臺任務，擁有相對較高運行時優先級；除非在內存及其不足威脅到前臺Activity的時候，這個組件才會被系統殺死。上述這種實現完全把Service當作一個普通的Java對象使用了，因此并沒有完全實現Service所具備的能力。

其次，Activity以及Service等組件是可以指定進程的，而讓Service運行在某個特定進程的情況非常常見——所謂的遠程Service；用上述這種辦法壓根兒沒有辦法讓某個Service對象運行在一個別的進程。Android系統給開發者控制進程的機會太少了，要么在AndroidManifest.xml中通過process屬性指定，要么借助Java的Runtime類或者native的fork；這幾種方式都無法讓我們以一種簡單的方式配合上述方案達到目的。

代理分發技術

既然我們希望插件的Service具有一定的運行時優先級，那么一個貨真價實的Service組件是必不可少的——只有這種被系統認可的真正的Service組件才具有所謂的運行時優先級。

因此，我們可以注冊一個真正的Service組件ProxyService，讓這個Service承載一個真正的Service組件所具備的能力（進程優先級等）；當啟動插件的服務比如PluginService的時候，我們統一啟動這個ProxyService，當這個ProxyService運行起來之后，再在它的onStartCommand等方法里面進行分發，執行PluginService的onStartCommond等對應的方法；我們把這種方案形象地稱為「代理分發技術」

代理分發技術也可以完美解決插件Service可以運行在不同的進程的問題——我們可以在AndroidManifest.xml中注冊多個ProxyService，指定它們的process屬性，讓它們運行在不同的進程；當啟動的插件Service希望運行在一個新的進程時，我們可以選擇某一個合適的ProxyService進行分發。也許有童鞋會說，那得注冊多少個ProxyService才能滿足需求啊？理論上確實存在這問題，但事實上，一個App使用超過10個進程的幾乎沒有；因此這種方案是可行的。

Service插件化的實現

現在我們已經設計出了Service組件的插件化方案，接下來我們以startService以及stopService為例實現這個過程。

注冊代理Service

我們需要一個貨真價實的Service組件來承載進程優先級等功能，因此需要在AndroidManifest.xml中聲明一個或者多個（用以支持多進程）這樣的Sevice：

攔截startService等調用過程

要手動控制Service組件的生命周期，需要攔截startService,stopService等調用，并且把啟動插件Service全部重定向為啟動ProxyService（保留原始插件Service信息）；這個攔截過程需要Hook ActvityManagerNative，我們對這種技術應該是輕車熟路了；不了解的童鞋可以參考之前的文章?Hook機制之AMS&PMS?。

 public static void hookActivityManagerNative() throws ClassNotFoundException,
        NoSuchMethodException, InvocationTargetException,
        IllegalAccessException, NoSuchFieldException {

    Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");

    Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
    gDefaultField.setAccessible(true);

    Object gDefault = gDefaultField.get(null);

    // gDefault是一個 android.util.Singleton對象; 我們取出這個單例里面的字段
    Class<?> singleton = Class.forName("android.util.Singleton");
    Field mInstanceField = singleton.getDeclaredField("mInstance");
    mInstanceField.setAccessible(true);

    // ActivityManagerNative 的gDefault對象里面原始的 IActivityManager對象
    Object rawIActivityManager = mInstanceField.get(gDefault);

    // 創建一個這個對象的代理對象, 然后替換這個字段, 讓我們的代理對象幫忙干活
    Class<?> iActivityManagerInterface = Class.forName("android.app.IActivityManager");
    Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
            new Class<?>[] { iActivityManagerInterface }, new IActivityManagerHandler(rawIActivityManager));
    mInstanceField.set(gDefault, proxy);
}
 

我們在收到startService,stopService之后可以進行具體的操作，對于startService來說，就是直接替換啟動的插件Service為ProxyService等待后續處理，代碼如下：

 if ("startService".equals(method.getName())) {
    // API 23:
    // public ComponentName startService(IApplicationThread caller, Intent service,
    //        String resolvedType, int userId) throws RemoteException
    // 找到參數里面的第一個Intent 對象
    Pair<Integer, Intent> integerIntentPair = foundFirstIntentOfArgs(args);
    Intent newIntent = new Intent();
    // 代理Service的包名, 也就是我們自己的包名
    String stubPackage = UPFApplication.getContext().getPackageName();
    // 這里我們把啟動的Service替換為ProxyService, 讓ProxyService接收生命周期回調
    ComponentName componentName = new ComponentName(stubPackage, ProxyService.class.getName());
    newIntent.setComponent(componentName);
    // 把我們原始要啟動的TargetService先存起來
    newIntent.putExtra(AMSHookHelper.EXTRA_TARGET_INTENT, integerIntentPair.second);
    
    // 替換掉Intent, 達到欺騙AMS的目的
    args[integerIntentPair.first] = newIntent;
    Log.v(TAG, "hook method startService success");
    return method.invoke(mBase, args);
}
 

對stopService的處理略有不同但是大同小異，讀者可以上?github?查閱源碼。

分發Service

Hook ActivityManagerNative之后，所有的插件Service的啟動都被重定向了到了我們注冊的ProxyService，這樣可以保證我們的插件Service有一個真正的Service組件作為宿主；但是要執行特定插件Service的任務，我們必須把這個任務分發到真正要啟動的Service上去；以onStart為例，在啟動ProxyService之后，會收到ProxyService的onStart回調，我們可以在這個方法里面把具體的任務交給原始要啟動的插件Service組件：

 public void onStart(Intent intent, int startId) {
    Log.d(TAG, "onStart() called with " + "intent = [" + intent + "], startId = [" + startId + "]");

    // 分發Service
    ServiceManager.getInstance().onStart(intent, startId);
    super.onStart(intent, startId);
}
 

加載Service

我們可以在ProxyService里面把任務轉發給真正要啟動的插件Service組件，要完成這個過程肯定需要創建一個對應的插件Service對象，比如PluginService；但是通常情況下插件存在與單獨的文件之中，正常的方式是無法創建這個PluginService對象的，宿主程序默認的ClassLoader無法加載插件中對應的這個類；所以，要創建這個對應的PluginService對象，必須先完成插件的加載過程，讓這個插件中的所有類都可以被正常訪問；這種技術我們在之前專門討論過，并給出了「激進方案」和「保守方案」，不了解的童鞋可以參考文章?插件加載機制；這里我選擇代碼較少的「保守方案」為例（Droid Plugin中采用的激進方案）：

 public static void patchClassLoader(ClassLoader cl, File apkFile, File optDexFile)
        throws IllegalAccessException, NoSuchMethodException, IOException, InvocationTargetException, InstantiationException, NoSuchFieldException {
    // 獲取 BaseDexClassLoader : pathList
    Field pathListField = DexClassLoader.class.getSuperclass().getDeclaredField("pathList");
    pathListField.setAccessible(true);
    Object pathListObj = pathListField.get(cl);

    // 獲取 PathList: Element[] dexElements
    Field dexElementArray = pathListObj.getClass().getDeclaredField("dexElements");
    dexElementArray.setAccessible(true);
    Object[] dexElements = (Object[]) dexElementArray.get(pathListObj);

    // Element 類型
    Class<?> elementClass = dexElements.getClass().getComponentType();

    // 創建一個數組, 用來替換原始的數組
    Object[] newElements = (Object[]) Array.newInstance(elementClass, dexElements.length + 1);

    // 構造插件Element(File file, boolean isDirectory, File zip, DexFile dexFile) 這個構造函數
    Constructor<?> constructor = elementClass.getConstructor(File.class, boolean.class, File.class, DexFile.class);
    Object o = constructor.newInstance(apkFile, false, apkFile, DexFile.loadDex(apkFile.getCanonicalPath(), optDexFile.getAbsolutePath(), 0));

    Object[] toAddElementArray = new Object[] { o };
    // 把原始的elements復制進去
    System.arraycopy(dexElements, 0, newElements, 0, dexElements.length);
    // 插件的那個element復制進去
    System.arraycopy(toAddElementArray, 0, newElements, dexElements.length, toAddElementArray.length);

    // 替換
    dexElementArray.set(pathListObj, newElements);

}
 

匹配過程

上文中我們把啟動插件Service重定向為啟動ProxyService，現在ProxyService已經啟動，因此必須把控制權交回原始的PluginService；在加載插件的時候，我們存儲了插件中所有的Service組件的信息，因此，只需要根據Intent里面的Component信息就可以取出對應的PluginService。

 private ServiceInfo selectPluginService(Intent pluginIntent) {
    for (ComponentName componentName : mServiceInfoMap.keySet()) {
        if (componentName.equals(pluginIntent.getComponent())) {
            return mServiceInfoMap.get(componentName);
        }
    }
    return null;
}
 

創建以及分發

插件被加載之后，我們就需要創建插件Service對應的Java對象了；由于這些類是在運行時動態加載進來的，肯定不能直接使用new關鍵字——我們需要使用反射機制。但是下面的代碼創建出插件Service對象能滿足要求嗎？

1 2	ClassLoader cl = getClassLoader(); Service service = cl.loadClass("com.plugin.xxx.PluginService1");

Service作為Android系統的組件，最重要的特點是它具有Context；所以，直接通過反射創建出來的這個PluginService就是一個殼子——沒有Context的Service能干什么？因此我們需要給將要創建的Service類創建出Conetxt；但是Context應該如何創建呢？我們平時壓根兒沒有這么干過，Context都是系統給我們創建好的。既然這樣，我們可以參照一下系統是如何創建Service對象的；在上文的Service源碼分析中，在ActivityThread類的handleCreateService完成了這個步驟，摘要如下：

 try {
    java.lang.ClassLoader cl = packageInfo.getClassLoader();
    service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
}

try {
    ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
    context.setOuterContext(service);

    Application app = packageInfo.makeApplication(false, mInstrumentation);
    service.attach(context, this, data.info.name, data.token, app,
            ActivityManagerNative.getDefault());
    service.onCreate();
 

可以看到，系統也是通過反射創建出了對應的Service對象，然后也創建了對應的Context，并給Service注入了活力。如果我們模擬系統創建Context這個過程，勢必需要進行一系列反射調用，那么我們何不直接反射handleCreateService方法呢？

當然，handleCreateService這個方法并沒有把創建出來的Service對象作為返回值返回，而是存放在ActivityThread的成員變量mService之中，這個是小case，我們反射取出來就行；所以，創建Service對象的代碼如下：

 /**
 * 通過ActivityThread的handleCreateService方法創建出Service對象
 * @param serviceInfo 插件的ServiceInfo
 * @throws Exception
 */
private void proxyCreateService(ServiceInfo serviceInfo) throws Exception {
    IBinder token = new Binder();

    // 創建CreateServiceData對象, 用來傳遞給ActivityThread的handleCreateService 當作參數
    Class<?> createServiceDataClass = Class.forName("android.app.ActivityThread$CreateServiceData");
    Constructor<?> constructor  = createServiceDataClass.getDeclaredConstructor();
    constructor.setAccessible(true);
    Object createServiceData = constructor.newInstance();

    // 寫入我們創建的createServiceData的token字段, ActivityThread的handleCreateService用這個作為key存儲Service
    Field tokenField = createServiceDataClass.getDeclaredField("token");
    tokenField.setAccessible(true);
    tokenField.set(createServiceData, token);

    // 寫入info對象
    // 這個修改是為了loadClass的時候, LoadedApk會是主程序的ClassLoader, 我們選擇Hook BaseDexClassLoader的方式加載插件
    serviceInfo.applicationInfo.packageName = UPFApplication.getContext().getPackageName();
    Field infoField = createServiceDataClass.getDeclaredField("info");
    infoField.setAccessible(true);
    infoField.set(createServiceData, serviceInfo);

    // 寫入compatInfo字段
    // 獲取默認的compatibility配置
    Class<?> compatibilityClass = Class.forName("android.content.res.CompatibilityInfo");
    Field defaultCompatibilityField = compatibilityClass.getDeclaredField("DEFAULT_COMPATIBILITY_INFO");
    Object defaultCompatibility = defaultCompatibilityField.get(null);
    Field compatInfoField = createServiceDataClass.getDeclaredField("compatInfo");
    compatInfoField.setAccessible(true);
    compatInfoField.set(createServiceData, defaultCompatibility);

    Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
    Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
    Object currentActivityThread = currentActivityThreadMethod.invoke(null);

    // private void handleCreateService(CreateServiceData data) {
    Method handleCreateServiceMethod = activityThreadClass.getDeclaredMethod("handleCreateService", createServiceDataClass);
    handleCreateServiceMethod.setAccessible(true);

    handleCreateServiceMethod.invoke(currentActivityThread, createServiceData);

    // handleCreateService創建出來的Service對象并沒有返回, 而是存儲在ActivityThread的mServices字段里面, 這里我們手動把它取出來
    Field mServicesField = activityThreadClass.getDeclaredField("mServices");
    mServicesField.setAccessible(true);
    Map mServices = (Map) mServicesField.get(currentActivityThread);
    Service service = (Service) mServices.get(token);

    // 獲取到之后, 移除這個service, 我們只是借花獻佛
    mServices.remove(token);

    // 將此Service存儲起來
    mServiceMap.put(serviceInfo.name, service);
}
 

現在我們已經創建出了對應的PluginService，并且擁有至關重要的Context對象；接下來就可以把消息分發給原始的PluginService組件了，這個分發的過程很簡單，直接執行消息對應的回調(onStart, onDestroy等）即可；因此，完整的startService分發過程如下：

 public void onStart(Intent proxyIntent, int startId) {

    Intent targetIntent = proxyIntent.getParcelableExtra(AMSHookHelper.EXTRA_TARGET_INTENT);
    ServiceInfo serviceInfo = selectPluginService(targetIntent);

    if (serviceInfo == null) {
        Log.w(TAG, "can not found service : " + targetIntent.getComponent());
        return;
    }
    try {

        if (!mServiceMap.containsKey(serviceInfo.name)) {
            // service還不存在, 先創建
            proxyCreateService(serviceInfo);
        }

        Service service = mServiceMap.get(serviceInfo.name);
        service.onStart(targetIntent, startId);
    } catch (Exception e) {
        e.printStackTrace();
    }
}
 

至此，我們已經實現了Service組件的插件化；完整的代碼見?github，代碼以startService, stopService為例進行了說明，bindService以及unbindService的原理是一樣的，感興趣的讀者可以自行實現；歡迎PR。

小節

本文中我們以綁定服務為例分析了Service組件的工作原理，并指出用戶交導致組件生命周期的變化是Activity與Service的根本差別，這種差別使得插件方案對于它們必須采取不同的處理方式；最后我們通過手動控制Service組件的生命周期結合「代理分發技術」成功地實現了Service組件的插件化；這種插件化方案堪稱「完美」，如果非要吹毛求疵，那只能說由于同一個進程的所有Service都掛載在同一個ProxyService上面，如果系統可用內存不夠必須回收Service，殺死一個ProxyService會導致一大票的插件Service歇菜。

實際使用過程中，Service組件的更新頻度并不高，因此直接把插件Service注冊到主程序也是可以接受的；而且如果需要綁定遠程Service，完全可以使用一個Service組件根據不同的Intent返回不同的IBinder，所以不實現Service組件的插件化也能滿足工程需要。值得一提的是，我們對于Service組件的插件化方案實際上是一種「代理」的方式，用這種方式也能實現Activity組件的插件化，有一些開源的插件方案比如?DL?就是這么做的。

迄今為止，我們講述了了Activity、BroadcastReceiver以及Service的插件化方式，不知讀者思索過沒有，實現插件化的關鍵點在哪里？

Service，Activity等不過就是一些普通的Java類，它們之所稱為四大組件，是因為他們有生命周期；這也是簡單地采用Java的動態加載技術無法實現插件化的原因——動態加載進來的Service等類如果沒有它的生命周期，無異于一個沒有靈魂的傀儡。對于Activity組件，由于他的生命周期受用戶交互影響，只有系統本身才能對這種交互有全局掌控力，因此它的插件化方式是Hook AMS，但是生命周期依然交由系統管理；而Service以及BroadcastReceiver的生命周期沒有額外的因素影響，因此我們選擇了手動控制其生命周期的方式。不論是借尸還魂還是女媧造人，對這些組件的插件化終歸結底是要賦予組件“生命”。

原文出處：　http://weishu.me/2016/05/11/understand-plugin-framework-service/

總結

以上是生活随笔為你收集整理的Android 插件化原理解析——Service的插件化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Android插件化原理解析——广播的管
下一篇： Android插件化原理解析——Cont