Android开发之组件化和插件化

2020-12-30 本文已影响0人冬日毛毛雨

组件化

组件化是一个老生常谈的问题，其实并不新鲜

组件化和模块化其实是一回事
不同的人对于它的定义是不一样的
定义:
- 拆成多个 module 开发就是组件化
- 以前的 Android 开发不是现在这样用 gradle 的，用的是 ant，做模块拆分比较麻烦
- 现在有了 gradle，拆模块非常方便了。不过模块化开发是在 gradle 到来之前就有了的

说下我的个人观点

这里比较下前端开发

前端的组件化和移动开发的组件化其实有类似但也有不同的地方
比如前端一个小的UI组件类似Android开发中的自定义UI，可以叫做组件，但是显然在移动开发中我们不会认为是一个组件，
- 在前端中组件的集合叫做组件库或者UI组件库，比如AntD，elementUI等
- 安卓也有UI组件库，比如QMUI等
Android开发中，我们依赖了很多module，组件和模块我认为可以统一但是也可以细分
- 首先实现方式上他们并没有什么区别，都是通过module依赖实现的
- 如果非要区分，可以通过不同的维度来区分
借鉴下前端思想，在前端开发中，component文件夹多用于存放UI组件，所以我现在这样定义
- 我认为组件更偏向的是UI，其内部主要是一些UI组件
  - 之所以把UI放在一起，是为了方便开发者查找和使用
  - 这样平时积累的UI组件就不必各自为战，也能统一地去管理
- 模块更加偏向的是功能，模块具备了完整的某一块业务流程，目的是为了降低与主工程的耦合，方便调用，也就是解耦，
  - 其内部可能是包含网络、图片、异步处理等
  - 甚至很多时候，模块也需要能够独立打包
我认为模块的粒度是大于组件的，其内部类文件/资源文件的职责和分类也更丰富些（毕竟组件可能只专注于UI），如果非要说某个组件库多少多少代码那我觉得就有些抬杠了

插件化

App 的部分功能模块在打包时并不以传统方式打包进 apk 文件中，而是以另一种形式二次封装进 apk内部，或者放在网络上适时下载，在需要的时候动态对这些功能模块进行加载，称之为插件化。
这些单独二次封装的功能模块 apk ，就称作「插件」，初始安装的 apk 称作「宿主」。
插件化是组件化的更进一步推进。

插件化基础：反射

反射基本使用

首先在我们的plugin目录下新建一个utils文件夹，里面写一个Utils类

class Utils {
    private static final String TAG = "Utils";
    void shout(){
        Log.d(TAG, "shout!!! ");
    }
}

然后在plugin包下新建一个使用它的Activity -> PluginActivity
由于Utils的访问权限都是默认的，所以无法在包外去实例它，所以要通过反射
- 对于类的实例化，需要通过构造方法去实例，实例方法要扩大访问权限setAccessible(true)
- 对于方法的调用，需要在获取方法之后并扩大访问权限setAccessible(true)
下面是完整代码

    public class PluginActivity extends AppCompatActivity {

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_plugin);

            //使用反射
            try {
                //1.拿到类
                Class utilsClass = Class.forName("com.dsh.txlessons.plugin.utils.Utils");
                //2.拿到第一个构造方法
                Constructor utilsConstructor = utilsClass.getDeclaredConstructors()[0];
                //3\. 扩大访问性 默认default包权限 -> public
                utilsConstructor.setAccessible(true);
                //4\. 创建类实例（通过构造方法实例）
                Object utils=utilsConstructor.newInstance();
                //5\. 获取方法
                Method shoutMethod = utilsClass.getDeclaredMethod("shout");
                //6\. 扩大方法访问权限
                shoutMethod.setAccessible(true);
                //7\. 方法执行
                shoutMethod.invoke(utils);
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (NoSuchMethodException e) {
                e.printStackTrace();
            } catch (InvocationTargetException e) {
                e.printStackTrace();
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        }
    }

反射的目的

Java 既然提供了可⻅性关键字 public private 等等，用来限制代码之间的可⻅性，为什么又要提供反射功能?

可⻅性特性的支持不是为了代码不被坏人使用，而是为了程序开发的简洁性。安全性的话，可⻅性的支持提供的是 Safety 的安全，而不是 Security 的安全。即，可⻅性的支持让程序更不容易写出 bug，而不是更不容易被人入侵。
反射的支持可以让开发者在可⻅性的例外场景中，可以突破可⻅性限制来调用自己需要的 API。这是基于对开发者「在使用反射时已经足够了解和谨慎」的假设的。
所以，可⻅性的支持不是为了防御外来者入侵，因此反射功能的支持并没有什么不合理。

插件化原理:动态加载

通过自定义 ClassLoader 来加载新的 dex 文件，从而让程序员原本没有的类可以被使用，这就是插件化的原理。

下面我们改造下代码

首先新建一个 module：「phone & Tablet Module」-> pluginapp
将app工程下utils文件夹移植到pluginapp工程下

改造app下PluginActivity反射代码,修改包名，其他不变

//1.拿到类
Class utilsClass = Class.forName("com.dsh.pluginapp.utils.Utils");

运行app，GG了，错误如下

Caused by: java.lang.ClassNotFoundException: Didn't find class "com.dsh.pluginapp.utils.Utils" on path: DexPathList[[zip file "/data/app/com.dsh.mydemos-q8nYNkNjIWB0F6mdYX_Gvg==/base.apk"] - 这个错误表示没有找到Utils这个类

2. 重点来了
上面的代码之所以会报错，是因为pluginapp同样是一个App工程，其本身经过打包也是一个apk的存在，所以我们app工程的类加载器是无法加载到pluginapp里面的类(.dex)文件的，所以才会报这样的错误
那么下面要解决的问题就是如何让app程序能够拿到pluginapp程序中的Utils
插件化的解决方案很粗暴，就是把插件工程的文件扔给宿主工程

下面我们实践一下

为了能够拿到插件工程中的文件，首先要将插件工程运行过后的apk复制到app工程的assets/apk目录下
现在我们拿到了apk，就可以通过DexClassLoader加载apk里面的类了
下面是代码，注释很详细

onCreate{
    ...
    //------------------  插件化使用  ------------------
    //1\. 将插件apk复制到缓存目录
    File apk = new File(getCacheDir()+"plugin.apk");
    try (Source source = Okio.source(getAssets().open("apk/pluginapp-debug.apk"));
         BufferedSink sink = Okio.buffer(Okio.sink(apk));){
        sink.writeAll(source);
    } catch (IOException e) {
        e.printStackTrace();
    }
    //2\. 创建类加载器实例
    DexClassLoader classLoader = new DexClassLoader(apk.getPath(),getCacheDir().getPath(),null,null);

    //3\. 反射调用
    //1.拿到类
    Class utilsClass = classLoader.loadClass("com.dsh.pluginapp.utils.Utils");
    //2.拿到第一个构造方法
    Constructor utilsConstructor = utilsClass.getDeclaredConstructors()[0];
    //3\. 扩大访问性 默认default包权限 -> public
    utilsConstructor.setAccessible(true);
    //4\. 创建类实例（通过构造方法实例）
    Object utils=utilsConstructor.newInstance();
    //5\. 获取方法
    Method shoutMethod = utilsClass.getDeclaredMethod("shout");
    //6\. 扩大方法访问权限
    shoutMethod.setAccessible(true);
    //7\. 方法执行
    shoutMethod.invoke(utils);
    ...
}

运行一下，正确输出了打印日志Shout at pluginApp

3. 现在普通的类能够加载了，那么Activity能够加载么？

看了一些其他博客，可以实现

插件的灵活配置

如果我们想要让插件工程既可以作为library又可以作为application，那么我们可以这样做

在项目的Project/build.gradle中添加一个变量
```
ext{
    fullBuild = false//全量打包
}
```

然后在插件工程pluginapp//build.gradle中通过变量判断要打包的类型

if (fullBuild){
    apply plugin: 'com.android.library'
}else {
    apply plugin: 'com.android.application'
}

插件化有什么用?

早期:解决 dex 65535 问题。谷歌后来也出了 multidex 工具来专⻔解决
一说:懒加载来减少软件启动速度:有可能，实质上未必会快
一说:减小安装包大小:可以
一说:项目结构拆分，依赖完全隔离，方便多团队开发和测试，解决了组件化耦合度太高的问题:这个使用模块化就够了，况且模块化解耦不够的话，插件化也解决不了这个问题
动态部署:可以
- Android App Bundles:属于「模块化发布」。未来也许会支持动态部署，但肯定会需要结合应用商店(即 Play Store，或者未来被更多的商店所支持)
bug 热修复:可以

关于 DEX:

class:java 编译后的文件，每个类对应一个 class 文件
dex:Dalvik EXecutable 把 class 打包在一起，一个 dex 可以包含多个 class 文件
odex:Optimized DEX 针对系统的优化，例如某个方法的调用指令，会把虚拟的调用转换为使用具体的 index，这样在执行的时候就不用再查找了
oat:Optimized Android file Type。使用 AOT 策略对 dex 预先编译(解释)成本地指令，这样再运行阶段就不需再经历一次解释过程，程序的运行可以更快
AOT:Ahead-Of-Time compilation 预先编译