Android开发之组件化和插件化

作者 : 开心源码 本文共5031个字,预计阅读时间需要13分钟 发布时间: 2022-05-13 共147人阅读

组件化

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

  • 组件化和模块化其实是一回事
  • 不同的人对于它的定义是不一样的
  • 定义:
    • 拆成多个 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 文件,从而让程序员本来没有的类可以被 使用,这就是插件化的原理。

  1. 下面我们改造下代码
  • 首先新建一个 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能够加载么?

看了少量其余博客,可以实现

  • 插件化——插桩式实现Activity跳转
  • Android插件化原理(一)Activity插件化
  • Android插件化探究(一)占位式(插桩式)插件化详解
  • Android插件化探究(二)hook式插件化详解
  • Android插件化探究(三)LoadedApk式插件化

插件的灵活配置

假如我们想要让插件工程既可以作为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 预先编译

相关学习书籍

Android 组件化架构Android 插件化指南

大家假如还想理解更多Android 相关的更多知识点,可以点进我的【GitHub项目中】自行查看,里面记录了许多的Android 知识点。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » Android开发之组件化和插件化

发表回复