一、Service 插件化思路

很可惜，Small不支持Service的插件化，但是在項目中我們確實有這樣的需求，那么就需要研究一下如何自己來實現Service的插件化。在討論如何實現Service的插件化之前，必須有三點準備：

掌握Service的基本知識，包括Service的生命周期、如何啟動和結束Service，bindService和startService之間的區別和聯系，這一部分就不過多介紹了，大家可以看一下 Carson_Ho 大神這篇文章，介紹的很全面 Android四大組件：Service服務史上最全面解析。
了解Service啟動的內部原理，對源碼進行一次簡單的走讀，主要是對Service調用者、所有者以及AMS之間的三方通信有一個清晰的認識，大家可以看一下我之前寫的這篇文章 Framework 源碼解析知識梳理(5) - startService 源碼分析。
掌握動態代理的知識，這里在前面分析Retrofit的時候也有介紹過，Retrofit 知識梳理(2) - Retrofit 動態代理內部實現。

在插件化知識梳理(6) - Small 源碼分析之 Hook 原理這篇文章中，我們一起學習了如何實現Activity的插件化，簡單地來說，實現原理就是：

在調用startActivity啟動插件Activity后，通過替換mInstrumentation成員變量，攔截這一啟動過程，在后臺偷偷地把startActivity時傳入的intent中的component替換成為在AndroidManifest.xml中預先注冊的占坑Activity，再通知ActivityManagerService。
當ActivityManagerService完成調度后，有替換客戶端中的ActivityThread中的mH中的mCallback，將占坑的Activity重新恢復成插件的Activity。

而Service的插件化也可以采用類似的方式，大體的思路如下：

在調用startService啟動插件Service時，通過攔截ActivityManagerProxy的對應方法，將Intent中的插件Service類型替換成預先在AndroidManifest.xml中預先注冊好的占坑Service。
當AMS通過ApplicationThreadProxy回調占坑Service對應的生命周期時，我們再在占坑Service中的onStartCommand中，去創建插件Service的實例，如果是第一次創建，那么先調用它的onCreate方法，再調用它的onStartCommand方法，否則，就只調用onStartCommand方法就可以了。
在調用stopService停止插件Service時，同樣通過攔截ActivityManagerProxy的對應方法，去調用插件Service的onDestroy，如果此時發現沒有任何一個與占坑Service關聯的插件Service運行時，那么就可以停止插件Service了。

二、具體實現

傳了一個簡單的例子到倉庫，大家可以簡單地對照著看一下，下面，我們開始分析具體的實現。

2.1 準備工作

初始化的過程如下所示：

    public void setup(Context context) {
        try {
            //1.通過反射獲取到ActivityManagerNative類。
            Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");
            Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
            gDefaultField.setAccessible(true);
            Object gDefault = gDefaultField.get(activityManagerNativeClass);

            //2.獲取mInstance變量。
            Class<?> singleton = Class.forName("android.util.Singleton");
            Field instanceField = singleton.getDeclaredField("mInstance");
            instanceField.setAccessible(true);

            //3.獲取原始的對象。
            Object original = instanceField.get(gDefault);

            //4.動態代理，用于攔截Intent。
            Class<?> iActivityManager = Class.forName("android.app.IActivityManager");
            Object proxy = Proxy.newProxyInstance(context.getClassLoader(), new Class[]{ iActivityManager }, new IActivityManagerInvocationHandler(original));
            instanceField.set(gDefault, proxy);

            //5.讀取插件當中的Service。
            loadService();

            //6.占坑的Component。
            mStubComponentName = new ComponentName(ServiceManagerApp.getAppContext().getPackageName(), StubService.class.getName());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

這里最主要的就是做了兩件事：

2.1.1 對 ActivityManagerNative.getDefault() 調用的攔截

這里應用到了動態代理的知識，我們用Proxy.newProxyInstance所創建的proxy對象，替代了ActivityManagerNative中的gDefault靜態變量。在 Framework 源碼解析知識梳理(1) - 應用程序與 AMS 的通信實現中，我們分析過，它其實是一個AMS在應用程序進程中的代理類。通過這一替換過程，那么當調用ActivityManagerNative.getDefault()方法時，就會先經過IActivityManagerInvocationHandler類，我們就可以根據invoke所傳入的方法名，在方法真正被調用之前插入一些自己的邏輯（也就是前文所說的，將啟動插件Service的Intent替換成啟動占坑Service的Intent），最后才會通過Binder調用到達AMS端，以此達到了“欺騙系統”的目的。

下面是InvocationHandler的具體實現，構造函數中傳入的是原始的ActivityManagerProxy對象。

    private class IActivityManagerInvocationHandler implements InvocationHandler {

        private Object mOriginal;


        public IActivityManagerInvocationHandler(Object original) {
            mOriginal = original;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            String methodName = method.getName();
            switch (methodName) {
                case "startService":
                    Intent matchIntent = null;
                    int matchIndex = 0;
                    for (Object object : args) {
                        if (object instanceof Intent) {
                            matchIntent = (Intent) object;
                            break;
                        }
                        matchIndex++;
                    }
                    if (matchIntent != null && ServiceManager.getInstance().isPlugService(matchIntent.getComponent())) {
                        Intent stubIntent = new Intent(matchIntent);
                        stubIntent.setComponent(getStubComponentName());
                        stubIntent.putExtra(KEY_ORIGINAL_INTENT, matchIntent);
                        //將插件的Service替換成占坑的Service。
                        args[matchIndex] = stubIntent;
                    }
                    break;
                case "stopService":
                    Intent stubIntent = null;
                    int stubIndex = 0;
                    for (Object object : args) {
                        if (object instanceof Intent) {
                            stubIntent = (Intent) object;
                            break;
                        }
                        stubIndex++;
                    }
                    if (stubIntent != null) {
                        boolean destroy = onStopService(stubIntent);
                        if (destroy) {
                            //如果需要銷毀占坑的Service，那么就替換掉Intent進行處理。
                            Intent destroyIntent = new Intent(stubIntent);
                            destroyIntent.setComponent(getStubComponentName());
                            args[stubIndex] = destroyIntent;
                        } else {
                            //由于在onStopService中已經手動調用了onDestroy，因此這里什么也不需要做，直接返回就可以。
                            return null;
                        }
                    }
                    break;
                default:
                    break;
            }
            Log.d("ServiceManager", "call invoke, methodName=" + method.getName());
            return method.invoke(mOriginal, args);
        }
    }

先看startService，args參數中保存了startService所傳入的實參，這里面就包含了啟動插件Service的Intent，我們將目標Intent的Component替換成為占坑的Component，然后將原始的Intent保存在KEY_ORIGINAL_INTENT字段當中，最后，通過原始的對象調用到ActivityManagerService端。

2.1.2 加載插件 Service 類

這里其實就是用到了前面介紹的DexClassLoader的知識，詳細的可以看一下前面的這兩篇文章插件化知識梳理(7) - 類的動態加載入門，插件化知識梳理(8) - 類的動態加載源碼分析。
最終，我們會將插件Service的Class對象保存在一個mLoadServices的Map當中，它的Key就是插件Service的包名和類名。

    private void loadService() {
        try {
            //從插件中加載Service類。
            File dexOutputDir = ServiceManagerApp.getAppContext().getDir("dex2", 0);
            String dexPath = Environment.getExternalStorageDirectory().toString() + PLUG_SERVICE_PATH;
            DexClassLoader loader = new DexClassLoader(dexPath, dexOutputDir.getAbsolutePath(), null, ServiceManagerApp.getAppContext().getClassLoader());
            try {
                Class clz = loader.loadClass(PLUG_SERVICE_NAME);
                mLoadedServices.put(new ComponentName(PLUG_SERVICE_PKG, PLUG_SERVICE_NAME), clz);
            } catch (Exception e) {
                e.printStackTrace();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

2.2 啟動插件 Service

接下來，在宿主中通過下面的方式啟動插件Service類：

    public void startService(View view) {
        Intent intent = new Intent();
        intent.setComponent(new ComponentName(ServiceManager.PLUG_SERVICE_PKG, ServiceManager.PLUG_SERVICE_NAME));
        startService(intent);
    }

按照前面的分析，首先會走到我們預設的“陷阱”當中，可以看到，這里面的Intent還是插件Service的Component名字：

然而，經過替換，最終調用時的Intent就變成了占坑的Service。

如果一切正常，接下來占坑Service就會啟動，依次調用它的onCreate和onStartCommand方法，我們在onStartCommand中，再去回調插件Service對應的生命周期：

public class StubService extends Service {

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d("StubService", "onCreate");
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Log.d("StubService", "onStartCommand");
        ServiceManager.getInstance().onStartCommand(intent, flags, startId);
        return super.onStartCommand(intent, flags, startId);
    }

    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        ServiceManager.getInstance().onDestroy();
        Log.d("StubService", "onDestroy");
    }
}

這里，我們取出之前保存在KEY_ORIGINAL_INTENT中原始的Intent，通過它找到對應插件Service的包名和類名，以此為key，在mLoadedServices中找到前面從插件apk中加載的Service類，并通過反射實例化該對象，如果是第一次創建，那么先執行它的onCreate方法，并將它保存在mAliveServices中，之后再執行它的onStartCommand方法。

這一過程的打印如下圖所示：

2.3 停止插件 Service

當我們通過stopService方法，停止插件Service時，也會和前面類似，先走到攔截的邏輯當中：

而在onStop方法中，我們判斷它是否是需要停止插件Service，如果是那么就調用插件Service的onDestory()方法，并且判斷與占坑Service相關聯的插件Service是否都已經結束了，如果是，那么就返回true，讓占坑Service也銷毀。

銷毀的時候，就是將插件Service的Intent替換成占坑Service：

這時的打印為：

三、總結

以上，就是實現插件化Service的核心思路，實現起來并不簡單，需要涉及到很多的知識，這已經是插件化學習的第十篇文章了。如果大家能一路看下來，可以發現，其實插件化并沒有什么神秘的地方，如果我們希望實現任意一個組件的插件化，無非就是以下幾點：

組件的生命周期。
組件的啟動過程，最主要就是和ActivityManagerService的交互過程，這也是最難的地方，要花很多的時間去看源碼，而且各個版本的API也可能有所差異。
插件化常用技巧，也就是Hook，動態代理之類的知識。
類動態加載的知識。

掌握了以上幾點，對于市面上大廠的插件框架基本能夠看懂個六七成，但是對于大多數人而言，并沒有這么多的時間和條件，去分析一些細節問題。我寫的這些文章，也只能算是入門水平，和大家一起學習基本的思想。真正核心的東西，還是需要有機會能應用到生產環境中才能真正掌握。

很可惜，我也沒有這樣的機會，感覺每天工作的時間都是在調UI、解Bug、浪費時間，只能靠著晚上的時間，一點點摸索，寫Demo，哎，說出來都是淚，還有半年，繼續加油吧！

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

插件化知識梳理(10) - Service 插件化實現及原理

插件化知識梳理(10) - Service 插件化實現及原理

相關閱讀

一、Service 插件化思路

二、具體實現

2.1 準備工作

2.1.1 對 ActivityManagerNative.getDefault() 調用的攔截

2.1.2 加載插件 Service 類

2.2 啟動插件 Service

2.3 停止插件 Service

三、總結

更多文章，歡迎訪問我的 Android 知識梳理系列：

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

插件化知識梳理(10) - Service 插件化實現及原理

相關閱讀

一、Service 插件化思路

二、具體實現

2.1 準備工作

2.1.1 對 ActivityManagerNative.getDefault() 調用的攔截

2.1.2 加載插件 Service 類

2.2 啟動插件 Service

2.3 停止插件 Service

三、總結

更多文章，歡迎訪問我的 Android 知識梳理系列：

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

一、Service 插件化思路