Android 组件化

前言

为什么要组件化?app 业务迭代,模块越来越多,代码量超10万是很正常的,代码混杂在一起,对工程所做的任何修改都必须要编译整个工程,维护成本越来越高,因此就需要进行模块化,组件化

Android工程的组件一般分为两种,lib组件和application组件。lib组件是指该组件属于app的一部分,可以供其它组件使用但是本身不能打包成apk;application组件是指该组件本身就可以运行并打包成app

定义

模块化:将一个程序按照其功能做拆分,分成相互独立的模块,以便于每个模块只包含与其功能相关的内容

组件化:将一个app分成多个模块,每个模块都是一个组件(Module),开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等,但是最终发布的时候是将这些组件合并统一成一个apk

插件化:和组件化开发略有不用,插件化开发时将整个app拆分成很多模块,这些模块包括一个宿主和多个插件,每个模块都是一个apk(组件化的每个模块是个lib),最终打包的时候将宿主apk和插件apk分开或者联合打包

区别

模块化 VS 组件化:模块化和组件化本质思想是一样的,都是"大化小",两者的目的都是为了重用和解耦,只是叫法不一样。如果非要说区别,那么可以认为模块化粒度更小,更侧重于重用,而组件化粒度稍大于模块,更侧重于业务解耦

组件化 VS 插件化:组件化可以说和插件化有异曲同工之妙,只不过插件化是在[运行时],而组件化是在[编译时]。换句话说,插件化是基于多APK的,而组件化本质上还是只有一个APK

优点

业务横向隔离、纵向解耦

系统级的控制力度细化到组件级的控制力度

沉淀出底层Library层,新建项目直接复用,节省人力

各组件可以采用灵活的架构形式:MVC、MVP、MVVP等

每个组件都有自己独立的版本,可以独立的编译、测试、打包和部署

为插件化做准备

组件化演变

简单开发模型:最基础的开发方式,工程中没有所谓的模块概念,项目组成的基本单位是方法。页面中夹杂着业务逻辑、数据操作、网络请求等

简单开发模型

单工程开发模型:明确的模块划分,并且通过逻辑上的分层呈现出较好结构,该模型最为我们所熟悉,通常用于早期产品的快速开发,团队规模较小的情况下

单工程开发模型

主工程多子工程开发模型:借助组件化这一思想,我们在”单工程”模型的基础上,将业务层中的各业务抽取出来,封装成相应的业务组件,将基础库中各部分抽取出来,封装成基础组件,而主工程是一个可运行的app,作为各组件的入口(主工程也被称之为壳程序)。这些组件或以jar的形式呈现,或以aar的形式呈现。主工程通过依赖的方式使用组件所提供的功能

主工程多子工程开发模型

不论是jar还是aar,本质上都是Library,他们不能脱离主工程而单独的运行。当团队中成员共同参与项目的开发时,每个成员的开发设备中必须至少同时具备主工程和各自负责组件,不难看出通过对项目实行组件化,每个成员可以专注自己所负责的业务,并不影响其他业务,同时借助稳定的基础组件,可以极大减少代码缺陷,因而整个团队可以以并行开发的方式高效的推进开发进度

不但如此,组件化可以灵活的让我们进行产品组装,要做的无非就是根据需求配置相应的组件,最后生产出我们想要的产品。这有点像玩积木,通过不同摆放,我们就能得到自己想要的形状

对测试同学而言,能有效的减少测试的时间:原有的业务不需要再次进行功能测试,可以专注于发生变化的业务的测试,以及最终的集成测试即可

所有业务组件不再是mouble而是作为一个子工程,基础组件可以是moudle,也可以是子工程。业务组件和主工程不同:Debug模式下下作为app,可以单独的开发、运行、调试;Release模式下作为Library,被主工程所依赖,向主工程提供服务


Android项目如何组件化?

组件化拆分流程图

组件间如何通信?可以采用开源的Router处理,核心是 Android 的 Scheme 机制。

UrlRouter   ||   ActivityRouter   ||    DeepLinkDispatch 

如何提升编译速度?业务组件在Debug模式下做为单独的Application,在Release模式下作为Library,如何去动态修改子工程的运行模式呢?

如何加快编译速度

注意事项

单一开闭原则:每个模块只代表一个功能模块或一个公共业务,对于个性化或定制功能以接口形式对外开放

拆分粒度:项目的演进是不断进行的,没必要将每个细小组件都拆分出来,这样不仅增加了项目的复杂度,同时也会影响编译时间

依赖关系:通过依赖图整理依赖关系,防止重复依赖,同时梳理出沉淀关系

组件间通信:放弃原来造成耦合严重的 EventBus,改用原生的隐式Intent通信方式,包括原生 (startActivityForResult) 、内部广播、回调等

资源冲突:为了解决不同Module间资源命名相同,资源调用时不知道调用哪个,建议每个Module的 *.gradle 添加  resourcePrefix "****_" ,****一般为模块名称,模块内每个资源文件命名以****为开头。但是涉及declare-styleable的资源命名比较长

ActivityNotFoundException:如果某个 Activity 移到底层之后,主工程中AndroidManifest 中对应的注册也应相应地迁移到对应 Module 的 AndroidManifest 中

Github:

Modularization 

推荐阅读更多精彩内容