Android组件化和插件化开发

2401_86968119

于 2024-09-10 05:07:22 发布

阅读量974

点赞数 19

文章标签： android

本文链接：https://blog.csdn.net/2401_86968119/article/details/142073699

版权

组件层：基础层往上是组件层，组件层就包含就是根据我们应用划分的业务组件，例如登录模块，消息模块等。
应用层：工程根据需要加入自己的业务组件。

组件化开发带来的优点：

业务模块分开，解耦的同时也降低了项目的复杂度，结构非常清晰。
开发调试时不需要对整个项目进行编译，每个模块可独立编译，提高了编译速度。
多人合作时可以只关注自己的业务模块，把某一业务当成单一项目来开发，可以提升开发，测试效率。
可以灵活的对业务模块进行组装和拆分。
避免重复造轮子，节省开发维护成本；

多个团队公用同一个组件，在一定层度上确保了技术方案的统一性。

总结：其实组件化更多的是适合于项目大但是功能相对集中的一些项目。比如一个金融类的App 里面只包含金融的功能，金融功能又会有借贷，理财，线下交易，把这些模块抽成单独的组件。

插件化开发

插件化是将一个apk根据业务功能拆分成不同的子apk（也就是不同的插件），每个子apk可以独立编译打包，最终发布上线的是集成后的apk。在apk使用时，每个插件是动态加载的，插件也可以进行热修复和热更新。它也是属于模块化的一种体现。不过它的单位是apk，一个完整的项目。灵活性在于加载apk，按需下载，动态更新。

如果一个应用所有的功能是非常多的，比如滴滴、美团、支付宝，他们除了一些基础的业务功能，还有其他的业务功能，如果都打成一个apk，文件将非常大，用插件化的方式开发后，apk只包含基础的业务功能，使用过程中用户可以按需加载自己需要的功能模块。

插件化的开发并没有一个官方的插件化方案，它是国内提出的一种技术实现，利用虚拟机的类的加载机制实现的一种技术手段，往往需要hook一些系统api，而Google从Android9.0开始限制对系统私有api的使用，也就造成了插件化的兼容性问题，现在几个流行的插件化技术框架，都是大厂根据自己的需求，开源出来的，如滴滴的VirtualAPK，360的RePlugin等。

总结：插件化开发适合于项目超级大但是功能相对不集中比如一个支付宝App 里面即包含共享单车也包含电影票。这种与本业务完全不同的可以做成插件的形式。

插件化和组件化的区别

| 技术 | 单位 | 实现内容 | 灵活性 | 特性 | 静动态 |

| — | — | — | — | — | — |

插件化和组件化的选择

理想的代码组织形式应该是插件化的方式，届时就具备了完备的运行时动态化，更灵活，各个插件的开发独立自主性更强。

但是目前还没有一个完美兼容的插件化方案。

选择插件化需要考虑两个方面：

兼容性。一是插件化不可避免的去 hook 一些系统的 api，也就不可避免地有兼容性的问题，因此每个插件化方案需要有专门的团队去负责维护；
开发节奏。二是从一个业务逻辑复杂的项目中去拆分插件化需要的时间可能是非常巨大的，同时把原有的项目集成到一个平台上，需要使用插件化的相关技术去修改，对Android四大组件的兼容性，对原来实现方式的适配都是一个挑战。
支持性。应用市场的支持：目前Google Play是不允许插件化的这种动态加载，增量更新方式的app上架的，因为这样会绕过审核，保不齐一些不良 App “挂羊头卖狗肉”，等用户下载、安装 App 之后，热更新出其他不良功能。目前国内市场还没明文规定。技术上的支持：一定程度上说，谷歌是不鼓励这种开发方式的，对私有api的限制以后会越来越严格，现有市场上的框架都是三年之前的。

大多数情况下，组件化都是一个不错甚至最佳的选择，它没有兼容性，可以更方便地拆分，并且几乎没有技术障碍，可以更顺利地去执行。特别是对急需拆分的产品来说，组件化是一个可退可守的方案，可以更快地执行下去，并且将来要是迁移到插件化，组件化拆分也是必经的一步。

最后

关于组件化方面的具体知识，推荐大家去看玉刚说和杨充两位大佬的两篇文章，个人感觉讲的很全面，也容易理解：