Android apk动态加载机制的研究（二）：资源加载和activity生命周期管理

时间 2019-11-17

标签 android apk 动态加载机制研究资源 activity 生命周期管理栏目 Android 繁體版

原文原文链接

转载请注明出处：http://blog.csdn.net/singwhatiwanna/article/details/23387079 （来自singwhatiwanna的csdn博客）
java

前言

为了更好地阅读本文，你须要先阅读Android apk动态加载机制的研究这篇文章，在此文中，博主分析了Android中apk的动态加载机制，并在文章的最后指出须要解决的两个复杂问题：资源的访问和activity生命周期的管理，而本文将会分析这两个复杂问题的解决方法。须要说明的一点是，咱们不可能调起任何一个未安装的apk，这在技术上是没法实现的，咱们调起的apk必须受某种规范的约束，只有在这种约束下开发的apk，咱们才能将其调起。另外，本文给出的解决方案也不是完美的，可是逻辑已经能够正常地跑通了，剩下的极个别细节问题是能够优化的。android

资源管理

咱们知道，宿主程序调起未安装的apk，一个很大的问题就是资源如何访问，具体来讲就是，凡是以R开头的资源都不能访问了，由于宿主程序中并无apk中的资源，因此经过R来加载资源是行不通的，程序会报错：没法找到某某id所对应的资源。针对这个问题，有人提出了将apk中的资源在宿主程序中也copy一份，这虽然能解决问题，能够一听起来就很奇怪，首先这样会持有两份资源，会增长宿主程序包的大小，其次，没发布一个插件都须要将资源copy到宿主程序中，这样就意味着每发布一个插件都要更新一下宿主程序，这和插件化的思想是相悖的，插件化的目的就是要减少宿主程序apk包的大小同时下降宿主程序的更新频率并作到自由装载模块。因此这种方法并不可行。还有人提供了一种方式：将apk中的资源解压出来，而后经过文件流去读取资源，这样作理论上是可行的，可是实际操做起来仍是有很大难度的，首先不一样资源有不一样的文件流格式，好比图片、xml等，还有就是针对不一样设备加载的资源多是不同的，若是选择合适的资源也是一个须要解决的问题，基于这两点，这种方法不建议使用，由于它实现起来有难度。下面说说本文所采用的方法。git

咱们知道，activity的工做主要是由ContextImpl来完成的，它在activity中是一个叫作mBase的成员变量。注意到Context中有以下两个抽象方法，看起来是和资源有关的，实际上context就是经过它们来获取资源的，这两个抽象方法的真正实如今ContextImpl中。也便是说，只要咱们本身实现这两个方法，就能够解决资源问题了。github

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

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

下面看一下如何实现这两个方法cookie

首先要加载apk中的资源：app

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中的资源了，这样咱们的问题就解决了。ide

/**
     * 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