Android apk動態加載機制的研究（二）：資源加載和activity生命週期管理

轉載請註明出處：http://blog.csdn.net/singwhatiwanna/article/details/23387079 （來自singwhatiwanna的csdn博客）

前言

爲了更好地閱讀本文，你須要先閱讀Android apk動態加載機制的研究這篇文章，在此文中，博主分析了Android中apk的動態加載機制，並在文章的最後指出須要解決的兩個複雜問題：資源的訪問和activity生命週期的管理，而本文將會分析這兩個複雜問題的解決方法。須要說明的一點是，咱們不可能調起任何一個未安裝的apk，這在技術上是沒法實現的，咱們調起的apk必須受某種規範的約束，只有在這種約束下開發的apk，咱們才能將其調起。另外，本文給出的解決方案也不是完美的，可是邏輯已經能夠正常地跑通了，剩下的極個別細節問題是能夠優化的。

資源管理

咱們知道，宿主程序調起未安裝的apk，一個很大的問題就是資源如何訪問，具體來講就是，凡是以R開頭的資源都不能訪問了，由於宿主程序中並無apk中的資源，因此經過R來加載資源是行不通的，程序會報錯：沒法找到某某id所對應的資源。針對這個問題，有人提出了將apk中的資源在宿主程序中也copy一份，這雖然能解決問題，能夠一聽起來就很奇怪，首先這樣會持有兩份資源，會增長宿主程序包的大小，其次，沒發佈一個插件都須要將資源copy到宿主程序中，這樣就意味着每發佈一個插件都要更新一下宿主程序，這和插件化的思想是相悖的，插件化的目的就是要減少宿主程序apk包的大小同時下降宿主程序的更新頻率並作到自由裝載模塊。因此這種方法並不可行。還有人提供了一種方式：將apk中的資源解壓出來，而後經過文件流去讀取資源，這樣作理論上是可行的，可是實際操做起來仍是有很大難度的，首先不一樣資源有不一樣的文件流格式，好比圖片、xml等，還有就是針對不一樣設備加載的資源多是不同的，若是選擇合適的資源也是一個須要解決的問題，基於這兩點，這種方法不建議使用，由於它實現起來有難度。下面說說本文所採用的方法。

咱們知道，activity的工做主要是由ContextImpl來完成的， 它在activity中是一個叫作mBase的成員變量。注意到Context中有以下兩個抽象方法，看起來是和資源有關的，實際上context就是經過它們來獲取資源的，這兩個抽象方法的真正實如今ContextImpl中。也便是說，只要咱們本身實現這兩個方法，就能夠解決資源問題了。

    /** Return an AssetManager instance for your application's package. */
    public abstract AssetManager getAssets();

    /** Return a Resources instance for your application's package. */
    public abstract Resources getResources();

下面看一下如何實現這兩個方法

首先要加載apk中的資源：

protected void loadResources() {
        try {
            AssetManager assetManager = AssetManager.class.newInstance();
            Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);
            addAssetPath.invoke(assetManager, mDexPath);
            mAssetManager = assetManager;
        } catch (Exception e) {
            e.printStackTrace();
        }
        Resources superRes = super.getResources();
        mResources = new Resources(mAssetManager, superRes.getDisplayMetrics(),
                superRes.getConfiguration());
        mTheme = mResources.newTheme();
        mTheme.setTo(super.getTheme());
    }

說明：加載的方法是經過反射，經過調用AssetManager中的addAssetPath方法，咱們能夠將一個apk中的資源加載到Resources中，因爲addAssetPath是隱藏api咱們沒法直接調用，因此只能經過反射，下面是它的聲明，經過註釋咱們能夠看出，傳遞的路徑能夠是zip文件也能夠是一個資源目錄，而apk就是一個zip，因此直接將apk的路徑傳給它，資源就加載到AssetManager中了，而後再經過AssetManager來建立一個新的Resources對象，這個對象就是咱們可使用的apk中的資源了，這樣咱們的問題就解決了。

/**
     * Add an additional set of assets to the asset manager.  This can be
     * either a directory or ZIP file.  Not for use by applications.  Returns
     * the cookie of the added asset, or 0 on failure.
     * {@hide}
     */
    public final int addAssetPath(String path) {
        int res = addAssetPathNative(path);
        return res;
    }

其次是要實現那兩個抽象方法

@Override
    public AssetManager getAssets() {
        return mAssetManager == null ? super.getAssets() : mAssetManager;
    }

    @Override
    public Resources getResources() {
        return mResources == null ? super.getResources() : mResources;
    }

okay，問題搞定。這樣一來，在apk中就能夠經過R來訪問資源了。

activity生命週期的管理

這是本文開頭提到的另外一個須要解決的難題。爲何會有這個問題，其實很好理解，apk被宿主程序調起之後，apk中的activity其實就是一個普通的對象，不具備activity的性質，由於系統啓動activity是要作不少初始化工做的，而咱們在應用層經過反射去啓動activity是很難完成系統所作的初始化工做的，因此activity的大部分特性都沒法使用包括activity的生命週期管理，這就須要咱們本身去管理。談到activity生命週期，其實就是那幾個常見的方法：onCreate、onStart、onResume、onPause等，因爲apk中的activity不是真正意義上的activity（沒有在宿主程序中註冊且沒有徹底初始化），因此這幾個生命週期的方法系統就不會去自動調用了。針對此類問題，採用Fragment是一個不錯的方法，Fragment從3.0引入，經過support-v4包，能夠兼容3.0如下的android版本。Fragment既有相似於Activity的生命週期，又有相似於View的界面，將Fragment加入到Activity中，activity會自動管理Fragment的生命週期，經過第一篇文章咱們知道，apk中的activity是經過宿主程序中的代理activity啓動的，將Fragment加入到代理activity內部，其生命週期將徹底由代理activity來管理，可是採用這種方法，就要求apk儘可能採用Fragment來實現，還有就是在作頁面跳轉的時候有點麻煩，固然關於Fragment相關的內容我將在後面再作研究，本文不採用Fragment而是經過反射去手動管理activity的生命週期。

咱們要在代理activity中去反射apk中activity的全部生命週期的方法，而後將activity的生命週期和代理activity的生命週期進行同步。首先，反射activity生命週期的全部方法，還反射了onActivityResult這個方法，儘管它不是典型的生命週期方法，可是它頗有用。

protected void instantiateLifecircleMethods(Class<?> localClass) {
        String[] methodNames = new String[] {
                "onRestart",
                "onStart",
                "onResume",
                "onPause",
                "onStop",
                "onDestory"
        };
        for (String methodName : methodNames) {
            Method method = null;
            try {
                method = localClass.getDeclaredMethod(methodName, new Class[] { });
                method.setAccessible(true);
            } catch (NoSuchMethodException e) {
                e.printStackTrace();
            }
            mActivityLifecircleMethods.put(methodName, method);
        }

        Method onCreate = null;
        try {
            onCreate = localClass.getDeclaredMethod("onCreate", new Class[] { Bundle.class });
            onCreate.setAccessible(true);
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        }
        mActivityLifecircleMethods.put("onCreate", onCreate);

        Method onActivityResult = null;
        try {
            onActivityResult = localClass.getDeclaredMethod("onActivityResult",
                    new Class[] { int.class, int.class, Intent.class });
            onActivityResult.setAccessible(true);
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        }
        mActivityLifecircleMethods.put("onActivityResult", onActivityResult);
    }

其次，同步生命週期，主要看一下onResume和onPause，其餘方法是相似的。看以下代碼，很好理解，就是當系統調用代理activity生命週期方法的時候，就經過反射去顯式調用apk中activity的對應方法。

@Override
    protected void onResume() {
        super.onResume();
        Method onResume = mActivityLifecircleMethods.get("onResume");
        if (onResume != null) {
            try {
                onResume.invoke(mRemoteActivity, new Object[] { });
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    
    @Override
    protected void onPause() {
        Method onPause = mActivityLifecircleMethods.get("onPause");
        if (onPause != null) {
            try {
                onPause.invoke(mRemoteActivity, new Object[] { });
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        super.onPause();
    }

插件apk的開發規範

文章開頭提到，要想成爲一個插件apk，是要知足必定條件的，以下是採用本文機制開發插件apk所須要遵循的規範：

1. 不能用this：由於this指向的是當前對象，即apk中的activity，可是因爲activity已經不是常規意義上的activity，因此this是沒有意義的。

2. 使用that：既然this不能用，那就用that，that是apk中activity的基類BaseActivity中的一個成員，它在apk安裝運行的時候指向this，而在未安裝的時候指向宿主程序中的代理activity，anyway，that is better than this。

3. 不能直接調用activity的成員方法：而必須經過that去調用，因爲that的動態分配特性，經過that去調用activity的成員方法，在apk安裝之後仍然能夠正常運行。

4. 啓動新activity的約束：啓動外部activity不受限制，啓動apk內部的activity有限制，首先因爲apk中的activity沒註冊，因此不支持隱式調用，其次必須經過BaseActivity中定義的新方法startActivityByProxy和startActivityForResultByProxy，還有就是不支持LaunchMode。

5. 目前暫不支持Service、BroadcastReceiver等須要註冊才能使用的組件。

後續工做

1. DLIntent的定義，經過自定義的intent，來完成activity的無約束調起

2. 採用Fragment的生命週期管理

3. Service、BroadcastReceiver等組件的調起

4. 性能優化

效果

首先宿主程序運行後，會把位於/mnt/sdcard/DynamicLoadHost目錄下的全部apk都加載進來，而後點擊列表就能夠調起對應的apk，本文中的demo和第一篇文章中的demo看起來差很少，實際是有區別的，區別有兩點：activity具備生命週期、加載資源能夠用R，具體的代碼實現請你們參見源碼。

源碼下載：https://github.com/singwhatiwanna/dynamic-load-apk