插件化知識梳理(6) Small 源碼分析之 Hook 原理

時間 2019-11-21

標籤插件知識梳理 small 源碼分析 hook 原理简体版

原文原文鏈接

1、前言

至此，花了四天時間、五篇文章，學習瞭如何使用Small框架來實現插件化。可是，對於我來講，一開始的目標就不是知足於僅僅知道如何用，而是但願經過這一框架做爲平臺，學習插件化中所用到的知識。android

對於許多插件化的開源框架而言，一個比較核心的部分就是Hook的實現，所謂Hook，簡單地來講就是在應用側啓動A.Activity，可是在AMS看來倒是啓動的B.Activity，以後AMS通知應用側後，咱們再從新替換成A.Activity。bash

在閱讀這篇文章以前，你們能夠先看一下以前的這篇文章 Framework 源碼解析知識梳理(1) - 應用進程與 AMS 的通訊實現，Small其實就是經過替換這一雙向通訊過程當中的關鍵類，對調用方法中傳遞的參數進行替換，來實現Hook機制。app

2、源碼分析

Hook的過程是Small預初始化的第一步，就是咱們前面在自定義的Application構造方法中所進行的操做：框架

public class SmallApp extends Application {

    public SmallApp() {
        Small.preSetUp(this);
    }

}
複製代碼

在Small的preSetUp(Application context)函數中，作了下面的兩件事：ide

實例化三個BundleLauncher的實現類，添加到Bundle類中的靜態變量sBundleLaunchers中，這三個類的繼承關係爲：函數
依次調用這個三個實現類的onCreate()方法。源碼分析

public static void preSetUp(Application context) {
        //1.添加關鍵的 BundleLauncher。
        registerLauncher(new ActivityLauncher());
        registerLauncher(new ApkBundleLauncher());
        registerLauncher(new WebBundleLauncher());
        //2.調用 BundleLauncher 的 onCreate() 方法。
        Bundle.onCreateLaunchers(context);
    }
複製代碼

對於以前添加進入的三個實現類，只有ApkBundleLauncher()實現了onCreate()方法，其它兩個都是空實現。學習

protected static void onCreateLaunchers(Application app) {
        //調用以前添加進入的 BundleLauncher 的 onCreate() 方法。
        for (BundleLauncher launcher : sBundleLaunchers) {
            launcher.onCreate(app);
        }
    }
複製代碼

咱們看一下ApkBundleLauncher的內部實現，這裏就是Hook的實現代碼：ui

@Override
    public void onCreate(Application app) {
        super.onCreate(app);

        Object/*ActivityThread*/ thread;
        List<ProviderInfo> providers;
        Instrumentation base;
        ApkBundleLauncher.InstrumentationWrapper wrapper;
        Field f;

        // Get activity thread
        thread = ReflectAccelerator.getActivityThread(app);

        // Replace instrumentation
        try {
            f = thread.getClass().getDeclaredField("mInstrumentation");
            f.setAccessible(true);
            base = (Instrumentation) f.get(thread);
            wrapper = new ApkBundleLauncher.InstrumentationWrapper(base);
            f.set(thread, wrapper);
        } catch (Exception e) {
            throw new RuntimeException("Failed to replace instrumentation for thread: " + thread);
        }

        // Inject message handler
        ensureInjectMessageHandler(thread);

        // Get providers
        try {
            f = thread.getClass().getDeclaredField("mBoundApplication");
            f.setAccessible(true);
            Object/*AppBindData*/ data = f.get(thread);
            f = data.getClass().getDeclaredField("providers");
            f.setAccessible(true);
            providers = (List<ProviderInfo>) f.get(data);
        } catch (Exception e) {
            throw new RuntimeException("Failed to get providers from thread: " + thread);
        }

        sActivityThread = thread;
        sProviders = providers;
        sHostInstrumentation = base;
        sBundleInstrumentation = wrapper;
    }
複製代碼

(1) 得到當前應用進程的 ActivityThread 實例this

首先，咱們經過反射得到當前應用進程的ActivityThread實例

thread = ReflectAccelerator.getActivityThread(app)
複製代碼

具體的邏輯爲：

public static Object getActivityThread(Context context) {
        try {
            //1.首先嚐試經過 ActivityThread 內部的靜態變量獲取。
            Class activityThread = Class.forName("android.app.ActivityThread");
            // ActivityThread.currentActivityThread()
            Method m = activityThread.getMethod("currentActivityThread", new Class[0]);
            m.setAccessible(true);
            Object thread = m.invoke(null, new Object[0]);
            if (thread != null) return thread;

            //2.靜態變量獲取失敗，那麼再經過 Application 的 mLoadedApk 中的 mActivityThread 獲取。
            Field mLoadedApk = context.getClass().getField("mLoadedApk");
            mLoadedApk.setAccessible(true);
            Object apk = mLoadedApk.get(context);
            Field mActivityThreadField = apk.getClass().getDeclaredField("mActivityThread");
            mActivityThreadField.setAccessible(true);
            return mActivityThreadField.get(apk);
        } catch (Throwable ignore) {
            throw new RuntimeException("Failed to get mActivityThread from context: " + context);
        }
    }
複製代碼

這裏面的邏輯爲：

經過ActivityThread中的靜態方法currentActivityThread來獲取：

public static ActivityThread currentActivityThread() {
        return sCurrentActivityThread;
    }
複製代碼

sCurrentActivityThread是在ActivityThread#attach(boolean)方法中被賦值的，而attach方法則是在入口函數main中調用的：

public static void main(String[] args) {
        //建立應用進程的 ActivityThread 實例。
        ActivityThread thread = new ActivityThread();
        thread.attach(false);
    }
複製代碼

若是上面的方法獲取失敗，那麼咱們再嘗試獲取Application中的LoadedApk#mActivityThread。

(2) 替換 ActivityThread 中的 mInstrumentation

經過(1)拿到ActivityThread實例以後，接下來就是替換其中mInstrumentation成員變量爲Small本身的實現類ApkBundleLauncher.InstrumentationWrapper，並將原始的mInstrumentation傳入做爲其成員變量。

正如 Framework 源碼解析知識梳理(1) - 應用進程與 AMS 的通訊實現中所介紹的，當咱們調用startActivity以後，那麼會調用到它內部的mInstrumentation的execStartActivity方法，通過替換以後，就會調用ApkBundleLauncher.InstrumentationWrapper的對應方法，下面截圖中的mBase就是原始的mInstrumentation：

ReflectAccelerator又經過反射調用了 mBase的對應方法：

因而可知， hook的目的就在於替代者的方法被調用，到調用原始對象的對應方法之間所進行的操做，也就是下面紅色框中的這兩句：

首先看一下wrap(Intent intent)方法，它的做用爲：當咱們在應用側啓動一個插件Activity時，須要將它替換成爲AndroidManifest.xml預先註冊好的佔坑Activity。

private void wrapIntent(Intent intent) {
            ComponentName component = intent.getComponent();
            String realClazz;
            //判斷是否顯示地設置了目標組件的類名。
            if (component == null) {
                //若是沒有顯示設置 Component，那麼經過 resolveActivity 來解析出目標組件。
                component = intent.resolveActivity(Small.getContext().getPackageManager());
                if (component != null) {
                    return;
                }

                //得到目標組件全路徑名。
                realClazz = resolveActivity(intent);
                if (realClazz == null) {
                    return;
                }
            } else {
                //若是設置了類名，那麼直接取出。
                realClazz = component.getClassName();
                if (realClazz.startsWith(STUB_ACTIVITY_PREFIX)) {
                    realClazz = unwrapIntent(intent);
                }
            }
            if (sLoadedActivities == null) return;
            //根據類名，肯定它是不是插件當中的 Activity 
            ActivityInfo ai = sLoadedActivities.get(realClazz);
            if (ai == null) return;
            //將真實的 Activity 保存在 Category 中，並加上 > 標識符。
            intent.addCategory(REDIRECT_FLAG + realClazz);
            //選取佔坑的 Activity 
            String stubClazz = dequeueStubActivity(ai, realClazz);
            //從新設置 intent，用佔坑的 Activity 來替代目標 Activity 
            intent.setComponent(new ComponentName(Small.getContext(), stubClazz));
        }
複製代碼

其中，dequeueStubActivity就是取出佔坑的Activity，它是預先在AndroidManifest.xml中註冊的一些佔坑Activity，同時，咱們也會把真實的目標Activity放在Category字段當中。

接下來，再看一下ensureInjectMessageHandler(Object thread)函數，代碼的邏輯很簡單，就是替換AcitivtyThread的mH中的mCallback變量爲sActivityThreadHandlerCallback，它的類型爲ActivityThreadHandlerCallback，是咱們自定的一個內部類。

private static void ensureInjectMessageHandler(Object thread) {
        try {
            Field f = thread.getClass().getDeclaredField("mH");
            f.setAccessible(true);
            Handler ah = (Handler) f.get(thread);
            f = Handler.class.getDeclaredField("mCallback");
            f.setAccessible(true);

            boolean needsInject = false;
            if (sActivityThreadHandlerCallback == null) {
                needsInject = true;
            } else {
                Object callback = f.get(ah);
                if (callback != sActivityThreadHandlerCallback) {
                    needsInject = true;
                }
            }

            if (needsInject) {
                // Inject message handler
                sActivityThreadHandlerCallback = new ActivityThreadHandlerCallback();
                f.set(ah, sActivityThreadHandlerCallback);
            }
        } catch (Exception e) {
            throw new RuntimeException("Failed to replace message handler for thread: " + thread);
        }
    }
複製代碼

在 Framework 源碼解析知識梳理(1) - 應用進程與 AMS 的通訊實現咱們分析過，Activity的生命週期是由AMS使用運行在系統進程的代理對象ApplicationThreadProxy，經過Binder通訊發送消息，在應用進程中的ActivityThread#ApplicationThread在onTransact()收到消息後，再經過mH（一個自定的Handler，類型爲H），發送消息到主線程，H在handleMessage中處理消息，回調Activity對應的生命週期方法。

而ensureInjectMessageHandler所作就是讓H的handleMessage方法被調用以前，進行一些額外的操做，例如在佔坑的Activity啓動完成以後，將它在應用測的記錄替換成爲Activity，而這一過程是經過替換Handler當中的mCallback對象，由於在調用handleMessage以前，會先去調用mCallback的handleMessage，而且在其不返回true的狀況下，會繼續調用Handler自己的handleMessage方法：

對於Small來講，它會對如下四種類型的消息進行攔截：

咱們以redirectActivity爲例，看一下將佔坑的Activity從新替換爲真實的Activity的過程。

private void redirectActivity(Message msg) {
            Object/*ActivityClientRecord*/ r = msg.obj;
            //經過反射得到啓動該 Activity 的 intent。
            Intent intent = ReflectAccelerator.getIntent(r);
            //就是經過前面放在 Category 中的字段，來取得真實的 Activity 名字。
            String targetClass = unwrapIntent(intent);
            boolean hasSetUp = Small.hasSetUp();
            if (targetClass == null) {
                if (hasSetUp) return; // nothing to do
                if (intent.hasCategory(Intent.CATEGORY_LAUNCHER)) {
                    return;
                }
                Small.setUpOnDemand();
                return;
            }
            if (!hasSetUp) {
                //確保初始化了。
                Small.setUp();
            }
            //從新替換爲真實的 Activity
            ActivityInfo targetInfo = sLoadedActivities.get(targetClass);
            ReflectAccelerator.setActivityInfo(r, targetInfo);
        }
複製代碼

因爲handleMessage的返回值爲false，按照前面的分析，mH的handleMessage方法也會獲得執行。

以上就是整個Hook的過程，簡單的總結下來就是在應用進程與AMS進程的通訊過程的某個節點，經過替換類的方式，插入一些邏輯，以繞過系統的檢查：

從應用進程到AMS所在進程的通訊，是經過替換應用進程中的ActivityThread的mInstrumentation爲自定義的ApkBundleLauncher.InstrumentationWrapper，在其中將Intent當中真實的Activity替換成爲佔坑的Activity，而後再調用原始的mInstrumentation通知AMS。
從AMS所在進行到應用進程的通訊，是經過替換應用進程中的H中的mCallback，在其中將佔坑Activity替換成爲真實的Activity，再執行本來的操做。

(3) ActivityThread 內部的 mBoundApplication 變量

這一步沒有進行Hook操做，而是先得到ActivityThread內部的mBoundApplication實例，而後得到該實例內部的providers變量，它的類型爲List<ProviderInfo>。

(4) 備份

最後一步，就是備份一些關鍵變量，用於以後的操做：

//ActivityThread 實例
        sActivityThread = thread;
        //List<ProviderInfo> 實例
        sProviders = providers;
        //原始的 Instrumentation 實例
        sHostInstrumentation = base;
        //執行 Hook 操做的 Instrumentation 實例
        sBundleInstrumentation = wrapper;
複製代碼

3、實例分析

以上就是源碼分析部分，下面，咱們經過一個啓動插件Activity的過程，來驗證一下前面的分析：

3.1 從應用進程到 AMS 進程

經過下面的方法啓動一個插件Activity：

public void startStubActivity(View view) {
        Small.openUri("upgrade", this);
    }
複製代碼

按照前面的分析，此時應當會調用通過Hook以後的Instrumentation實例的execStartActivity方法，能夠看到在wrapIntent方法調用以前，咱們的目標Activity仍然是真實的UpgradeActivity：

讓斷點繼續往下走，通過 wrapIntent以後， Intent的目標對象替換成爲了佔坑的 Activity：

3.2 從 AMS 進程到應用進程

而當AMS須要通知應用進程時，它第一次回調的是佔坑的Activity，也就是以下所示：

經過反射，咱們修改 ActivityClientRecord中的內容，讓其還原成爲真實的 Activity：

4、小結

以上就是Small預初始化所作的一些事情，也就是其Hook實現的原理，不少第三方的插件化都是基於該原理來實現啓動不在AndroidManifest.xml中註冊的組件的，開始的時候，理解起來可能會有點困難，關鍵是要弄清楚應用程序和AMS進程的交互原理，歡迎閱讀 Framework 源碼解析知識梳理(1) - 應用進程與 AMS 的通訊實現。