Android组件化演进-第一篇

背景

近年来，组件化一直是业界积极探索和实践的方向，越来越多的公司使用组件化来构建项目，我们公司在组件化实践方向也有了一些实践，但目前还没有一个标准，这也是我们为什么要整理这个文档的目的，确定一下组件化的方案，为未来的复杂业务助力。

组件化带来的优势

首先组件化的一些优势是我们应用它的核心价值，那么都有哪些优势呢？大致总结如下： 1.加快项目编译速度，提高开发效率，因为模块可以独立编译、测试、打包和部署 2.提高组件的复用 3.避免了模块之间的交叉依赖，做到低耦合、高内聚 4.引用的第三方库代码统一管理，避免版本不统一，减少引入冗余库

组件化目标

首先设立一个目标，来保证我们后续不偏离方向，不能为了组件化而组件化，复杂的设计必定会造成大量的学习成本，反而会降低开发效率，其实我们设计组件化的初衷也是为了能更加简单化，而且目标促使我们价值观统一，大家朝一个方向努力，共同创造价值。 如下： 1.生成组件化模版项目，能够快速的迭代新项目 2.组件化脚手架，可定制化

组件化规范

1.代码尽可能的解耦

• 对项目进行模块拆分，模块分为两种类型，一种是功能组件模块，封装一些公共的方法服务等，作为依赖库对外提供；另一种是业务组件模块，专门处理业务逻辑等功能，这些业务组件模块最终负责组装APP。

2.每个组件都可单独运行

• 每个组件都是高度内聚的，是一个完整的整体
• 通过 Gradle脚本配置方式，进行不同环境切换

3.组件间通信

• 通过路由的方式进行通信（路由框架待选择）

4.规范组件生命周期

• 生命周期指的是组件在应用中存在的时间，组件是否可以做到按需、动态使用、因此就会涉及到组件加载、卸载等

5.严格限制公共基础组件的增长

• 随着开发不断进行，要注意不要往基础公共组件加入太多内容。而是应该减小体积！倘若是基础组件过于庞大，那么运行组件也是比较缓慢的

组件化常见问题以及解决方案

1.通信 通信这个需要考虑两个方面，一个是同进程之间，一个是跨进程之间，那么就会有两种解决方案如下： 同进程： 接口依赖调用 跨进程： https://github.com/iqiyi/Andromeda Andromeda提供了接口式的组件间通信管理，包括同进程的本地接口调用和跨进程接口调用。 2.初始化

• https://developer.android.com/topic/libraries/app-startup google官方
• https://github.com/bingoogolapple/AppInit AppInit 用于解决美团收银 B 端 App 在业务演进过程中的实际问题

3.代码隔离，如何处理依赖关系 这里推荐美团的组件化方案：把每个业务组件都拆分成了一个Export Module和Implement Module。这样的话，如果Module A需要调用Module B提供的接口，同时Module B需要调用Module A的接口，只需要Module A依赖Module B Export，Module B依赖Module A Export就可以了。

4.页面跳转

• ARouter
• Navigation

Navigation这里单独拿出来讲一下，其实在用到Navigation时有很多好处，如下：

• 可以实现单Activity+多Fragment架构，好处就在于Fragment比Activity更轻量级，从而减少内存占用，其实Activity与Activity之间存在进程通信以及其他开销。
• 结合Flutter这种框架，我们发现，它的一个页面由多个Widget组成，页面更加灵活，同样的Fragment也是一样，它需要放在Activity中，且灵活可配。
• 官方支持，放心使用

Navigation 组件化项目：https://github.com/VMadalin/android-modular-architecture

组件化架构图设计

components-ac.png

以上设计图，遵循组件化规范。详细介绍请往下看。

模块介绍

1.业务组件这一层，主要是能否独立业务的组件，如登陆模块可以抽离出一个完整的组件，并可以打包出独立的app包。 2.功能组件 • Common：包含公共业务接口定义，数据模型，数据库相关。• 自定义View：一些特殊样式，或者组合使用的自定义View • 日志：日志框架组件，如logan • 推送：push消息等组件，独立于业务• 分享：分享SDK • 视频：视频相关功能组件• 即时通讯：聊天实时消息相关组件 3.Core基础层：

1. 网络请求(采用 Retrofit+协程)
2. 图片加载(策略模式，Glide 与 Picasso或者coil 之间可以切换)
3. 基类 Adapter 的封装（支持 item动画、多布局item、下拉和加载更多、item点击事件）
4. 通用的工具类，Kotlin版本的动态扩展（Context、Fragment、Activity、Service、Intent等）
5. 协程封装
6. 其他等等 4.BuildSrc + Composite Builds Module BuildSrc的运用更好的Gradle依赖关系管理，Composite Builds提升构建速度，编写自定义插件。且统一管理框架版本信息，防止组件之间框架依赖版本冲突问题

组件化脚手架介绍

首先说下为什么要设计脚手架，这个源于SpringBoot脚手架的灵感，因为组件化后，项目各个模块相对独立，如果我们开发新项目就会遇到各种各样的功能，且符合我们的实际场景需求，如： 咨询师没有数据库，而其他app都需要数据库存储。小猫大部分是离线处理，而ESA又都是后台处理，每个业务都有不同的特点，所以我们想做一个可定制化的组件化项目，而不是一成不变。 脚手架的开发也是我们设计的一个目标，设计如下： image.png image.png

此脚手架我们做的是在线的，傻瓜式操作，只需要在页面中选择已经配置好的模版，可定制如下：

1. 包名
2. 语言
3. 最低兼容版本
4. 架构选择
5. 组件依赖

当然这个页面的设计还不够完善，没有体现可以依赖三方框架，这个我们也会在未来的设计中加入进去，结合我们公司实际的业务场景，来做到定制化生成。

讨论结论

目前待确认框架选型如下：

1. 不使用单Activity+多Fragment架构（此点考虑到C端已经在用多Activity，且单Activity并没有更好的实践结果，所以保持原有架构）
2. 数据库考虑升级为moshi，或者kotlin官方serialization，去除Gson逻辑，后续专门做专题讨论
3. 网络层抛弃Rxjava方式，未来用okhttp+协程方式，后续专门做专题讨论
4. 页面跳转依然适用Arouter
5. 组件初始化目前有贤论大佬自开发方案和google官方或美团相关方案，待后续专门专题讨论
6. gradle build方式更新为 kotlin dsl gradle

参考项目

https://github.com/hegaojian/JetpackMvvm https://github.com/goldze/MVVMHabitComponent https://github.com/getActivity/AndroidProject https://github.com/android/sunflower
https://github.com/KunMinX/Jetpack-MVVM-Best-Practice
https://github.com/skydoves/Pokedex
https://github.com/VMadalin/android-modular-architecture
https://github.com/qingmei2/MVVM-Architecture