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

 

前言

為了更好地閱讀本文，你需要先閱讀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