[Android]如何做一个崩溃率少于千分之三噶应用app(23)-组件化&模块化&插件化演进

大家好,我系苍王。

以下是我这个系列的相关文章,有兴趣可以参考一下,可以给个喜欢或者关注我的文章。

[Android]如何做一个崩溃率少于千分之三噶应用app--章节列表


写了二十多篇的简书,到这里已经写了很多关于很多组件化内容的文章,但是很多对组件化,模块化,插件化的概念还是不理解。

很多同学,都觉得如何划分模块,如何划分组件,如何做隔离解耦,如何做分层产生了疑虑,有些时候无从下手。

这里还是需要给大家普及一下概念性的说明吧。


一.组件化

关于组件化,看过我第一编开篇文章的,会看到这个图。

这个图其实是我们组件化入门所接触到的图,这样简单的分明的分层。


基础组件化图

(1)base module集成基础用到的组件

(2)一个组件意为着一个业务

(3)App module是统筹每个的集成层。

这是最基础最简陋的组件化工程,比较适合中小型开发项目架构。其基础的接口,例如存储io,图片等,需要轻量级封装,只需要使用一个类封装就可以了。而业务独立简单,只需要一个base module即可以完成基础依赖。


二.模块化

架构都是从基础演化的,随着业务量的增加,就会发现层级有点不够用了,业务需要更加细分,然后就进化到模块化的模型。

这是我理解的模块化。

这里很清晰可以看到我将模块化分为5层模型。


模块化模型图

(1)应用层是生成app和初始化操作的加载

(2)模块层,每个模块相当于一个业务,通过module来分隔开每个业务的逻辑。

(3)基础层,基础组件的整合,提供基础组件能力给业务层使用。

(4)组件层,通过图片加载,网络http,socket等基础功能划分为一层。

(5)基础库层,更加基础的库类依赖,此层非必须,例如(Rxjava,EventBus等一些代码结构优化的库),还有自己编写的封装类。

这里业务层,调试之前gradle组件化优化和组件化数据分享都有给大家介绍。

基础库层,这个层是可以转移到基础层和组件层混合的中,这样可以减少层级,所以为虚线。

这个结构适合中型app的搭建,当你在第一种组件化架构有相对的沉淀,发现业务需要重新细分重构的时候,可以考虑这种架构方式。其要求组件独立复用,模块也可以独立复用。而其组件集合和模块关联就是依赖于一个Base module来完成。

还有模块化更进一步架构方式和需求,以后有机会再给大家介绍。


三.插件化

当业务层相对独立后,分层已经非常稳定。

国内Android App大环境(作为用户,用户都贪新忘旧的,每一星期半个月就重新下载app,谁受得了。)。这种环境下,中国黑科技热更新就变为了常态。热更新催生出插件化开发。·

那么架构只能再次进化。

依然是沿用上面的5层模型。


插件化模型图

我们可以看到上面的插件化模型。

(1)组件层里面需要添加插件框架,如Small,Atlas,DroidPlugin等等,至于选型之前有推荐一系列的文章。

(2)开发模块层,其业务分块相当于一些大型的业务作为独立的插件,例如地图,直播间,活动,第三方嵌入等。作为单独的研发分支(svn,git工程),这样作为基础项目研发,就保有其模块的独立性,最大程度解耦。

(3)应用层,对应着宿主App(不知道的,就去补插件基础去吧),一些非常基础的业务如登录,支付等需要账号等数据最好集成到这里。当然如果公司对于这些分块一定有很好的解决能力和条件。宿主App相当于只是一个壳,包装加载全部的插件App还是没问题的。

这样的架构,适合模块迭代,有一个小组来完成即可小工程,而且可以脱离原来大工程的研发。但是这里需要注意的一点,需要非常小心的设置base module里面的模块间通信。举个例子,倘若用RxBus来通信,其每次都需要添加一个新的类,那么每次都需要更改添加到base module,那么其架构是非常不稳定,更新也是不允许向前兼容,而且模块多了,功能叠加会造成类爆炸。除非重构,接口的设计向前兼容,那么旧的接口就不能作过多的修改,不能删除和更改参数,只能增加。所以这里请各位架构师一定要思考清楚以后的重构难度。


这里还给出插件化运行模型。


插件化运行模型

插件化,研发阶段考虑的问题

(1)资源冗余解决,包括对于base module的依赖和库依赖

(2)混淆相关和资源冲突

(3)插件加载方式

(4)通信依赖,数据交互,事件触发


可以看到组件化,模块化,插件化一步步演进的过程,应该会适合大家各种大中小型项目的业务重构。

这一篇并不是讲习一些研发技术,只是介绍组件化的研发思维和扩展,给大家一种统筹的思想,更加深入理解组件化的精粹。


到这里,同学们是否已经感受到对组件化架构体系是否已经有更加深刻的理解了?

那么是否插件化后是否更加清晰和高效的架构呢?

我可以提示,之后将会进程化,如何实现进程化?我将会在我之后新开的系列给大家进一步讲解。敬请期待吧!!!



这一节介绍就到这里,

下一节将会更精彩,敬请期待!!!

群号是316556016,也可以扫码进群。我在这里期待你们的加入!!!

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值