Android进阶——组件化开发实践(一)

一、组件化的意义

随着Android 项目代码和结构逐渐复杂,维护成本会指数型上升,通常我们会利用Android Studio自带的Module去拆分项目代码。但这种拆分显然需要基于一定逻辑和结构,目前主流的拆分思路有两种:分别是①基于业务拆分;②基于功能拆分。前者通常会将一个App划分为若干模块,每一个模块对应一个Module。如一个短视频APP(类似某音)通常会被拆分为:首页、登录模块、视频模块、广告模块、直播模块…
但是这样划分会带来一个问题:模块与模块之前会存在重复功能,比如视频模块和直播模块中会同时存在视频解码、流媒体播放等相关功能;但如果把两个模块合并又会导致代码量过于庞大,且上层业务并不存在强关联,这显然违背了软件工程中的低耦合高内聚的基本原则。这就要引出我们的组件化了,也就是第二种拆分方式了:基于功能拆分。还是以一个短视频App举例,基于功能拆分通常会将一个App拆分为三个层次,分别是基础层、组件层和业务层
在这里插入图片描述

基础库 :主要是一些通用的和业务无任何关联的功能,如:网络通信、音视频解码播放、数据存储、SP操作、图片加载等,这部分会统一放在一个Module下,每一个小功能对应一个或多个类;
组件层 :主要是按照业务功能进行拆分的独立功能,这部分是业务核心逻辑代码,如登录组件、个人中心组件、直播核心组件等,通常每一个组件对应一个Module;
业务层 :具体的用户可感知的业务模块,由一个或多个组件组成,如直播功能模块包括直播核心组件和礼物组件。
注:上图只是简单列一下便于理解组件化拆分逻辑,实际场景下会比这个图复杂。

二、组件化带来的优点

  1. 业务模块分开,解耦的同时也降低了项目的复杂度,结构非常清晰,如需替换某项组件,只需保持接口不变,替换过程中上层业务无感知,比较典型的场景就是更换项目的网络通信库、图片加载库;
  2. 每个模块可独立编译,提高了编译速度(在巨无霸型APP中效果尤为明显);
  3. 需求可以基于组件拆分,多人协同完成同一需求时可以显著提升效率;
  4. 可以灵活的对业务模块进行组装和拆分;
  5. 避免重复造轮子,节省开发维护成本;

三、组件化需要解决的问题

从上面的结构图其实也可以看出,对于一个项目进行组件化改造,其路径不是唯一的,如对于上图中的直播场景,可以拆分为直播核心组件+礼物打赏组件+其他附属组件,当然也可以拆分为直播视频组件+礼物及交易组件+打赏组件+其他附属组件,这两种并没有绝对的孰优孰劣。但是组件化需要解决的问题是确定的,当你需要对项目进行组件化改造时,一定是以组件化需要解决的问题作为出发点,主要问题包括:

  1. 每个组件都是一个完整的整体,所以组件开发过程中要满足单独运行及调试的要求,这样还可以提升开发过程中项目的编译速度(大型Android项目编译一次30分钟+真不是闹着玩的)。
  2. 数据传递与组件间方法的相互调用,这也是上面我们提到的一个必须要解决的问题。
  3. 组件间界面跳转,不同组件之间不仅会有数据的传递,也会有相互的页面跳转。在组件化开发过程中如何在不相互依赖的情况下实现互相跳转?
  4. 主项目不直接访问组件中具体类的情况下,如何获取组件中 Fragment 的实例并将组件中的 Fragment 实例添加到主项目的界面中?
  5. 组件开发完成后相互之间的集成调试如何实现?还有就是在集成调试阶段,依赖多个组件进行开发时,如果实现只依赖部分组件时可以编译通过?这样也会降低编译时间,提升效率。
  6. 组件解耦的目标以及如何实现代码隔离?不仅组件之间相互隔离,还有第五个问题中模块依赖组件时可以动态增删组件,这样就是模块不会对组件中特定的类进行操作,所以完全的隔绝模块对组件中类的使用会使解耦更加彻底,程序也更加健壮。

*关于组件化在项目中的具体代码实践,埋个坑,关注后续系列博客~~~~*

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值