插件化的基本概念与基本原理-CSDN博客

插件化的基本概念

我们在第一篇文章中就介绍过插件化的基本概念，这里再强调一次。

随着下面这些问题的出现：

APP的体积越来越大，功能模块越来越多
模块之间的耦合度高，协同开发沟通成本越来越大
方法数目可能超过65535，APP占用的内存过大

相应的解决办法：

将一个大的APK按照业务划分为多个小的APK
每个小的APK又可以独立运行、又可以依附于宿主APK运行

那么，就会有如下优势：

业务模块之间基本完全解偶
协同并行开发成为可能，提高了Gradle的编译速度
业务模块可以按照需要进行加载，降低内存的占用

于是乎，插件化的技术油然而生。

在插件化的技术中，有几个常见的属于：

宿主：主APP，也叫作Host，它可以独立运行，也可以加载插件。宿主必须安装到用户手机上，提供基本的类库与功能
插件：也叫作Plugin，跟普通APP一样，可以独立运行，也可以由宿主进行加载
插件化：将一个应用按照宿主&插件的方式改造的过程就叫做插件化

以Small为例，应用插件化改造后的项目架构如下（Small框架的插件以so为后缀）：

插件化与组件化、热修复的对比

插件化与组件化的对比：

组件化是一种编程思想，插件化是一种技术
组件化是为了提高代码的高度可复用性；插件化是为了解决应用越来越庞大等问题而出现的

插件化与热修复（动态更新）对比：

两者都是动态加载技术的应用
使用场景不同，热修复是为了解决线上的不过或者小功能的更新而出现的；插件化是为了解决应用越来越庞大等问题而出现的

具体的区分可以用下图来展示：

插件化原理

插件化的核心原理有一下几点：

Class文件加载Dex原理
Android资源加载与管理
四大组件的加载与管理
Java反射原理
so库的加载原理
Android系统服务的运行原理
Gradle打包原理
清单文件的合并处理

不同的框架，原理都有差异，鉴于文章篇幅，在这里只介绍最核心、最重要的部分。

Dex（APK）的加载原理

首先我们需要掌握Android Classloader的分类和基本原理，这在前面的文章中已经有所介绍。

Dex（APK）的加载相关的核心代码如下：

private void loadApk(String apkPath) {
    File optDir = getDir("opt", MODE_PRIVATE);
    //初始化classLoader，optDir是Dex文件的解压目录
    DexClassLoader classLoader = new DexClassLoader(apkPath,
            optDir.getAbsolutePath(), null, this.getClassLoader());

    try {
        Class cls = classLoader.loadClass("具体的一个类");
        if (cls != null) {
			//通过反射创建对象、调用方法
            Object instacne = cls.newInstance();
            Method method = cls.getMethod("方法名");
            method.invoke(instacne);
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
}
复制代码

一般来说，插件化框架都会进行自定义ClassLoader，以便于更好地管理并维护ClassLoader：

public class CustomClassLoader extends DexClassLoader {

    public CustomClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
        super(dexPath, optimizedDirectory, librarySearchPath, parent);
    }


    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = getClassData(name);
        if (classData != null) {
            return defineClass(name, classData, 0, classData.length);
        } else {
            throw new ClassNotFoundException();
        }
    }

    private byte[] getClassData(String name) {
        try {
            InputStream inputStream = new FileInputStream(name);
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int buffersize = 4096;
            byte[] buffer = new byte[buffersize];
            int bytesNumRead = -1;
            while ((bytesNumRead = inputStream.read(buffer)) != -1) {
                baos.write(buffer, 0, bytesNumRead);
            }
            return baos.toByteArray();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }
}
复制代码

可以看到这里改写了findClass方法，先通过自己的getClassData方法去查找类，防止了加载不同Dex文件的同一个类不会被重复加载的问题。

Android资源加载与管理

AssetManager、resoures等类与资源的加载与管理息息相关，无论是加载有ID或者没有ID的文件，如下图所示：

插件化框架需要为每个插件创建对应的加载器、AssetManager、resoures。代码如下所示：


//为插件apk创建对应的classLoader
private static DexClassLoader createPluginDexClassLoader(String apkPath) {

    DexClassLoader classLoader = new DexClassLoader(apkPath,
            mOptFile.getAbsolutePath(), null, null);
    return classLoader;
}

//为对应的插件创建AssetManager
private static AssetManager createPluginAssetManager(String apkPath) {

    try {
        AssetManager assetManager = AssetManager.class.newInstance();
        Method addAssetPath = assetManager.getClass().getMethod("addAssetPath",
                String.class);

        addAssetPath.invoke(assetManager, apkPath);
        return assetManager;
    } catch (Exception e) {
        e.printStackTrace();
    }

    return null;
}

//为对应的插件创建resoures
private static Resources createPluginResources(String apkPath) {

    AssetManager assetManager = createPluginAssetManager(apkPath);

    Resources superResources = mContext.getResources();

    Resources pluginResources = new Resources(assetManager,
            superResources.getDisplayMetrics(), superResources.getConfiguration());

    return pluginResources;
}
复制代码