背景
近年来，组件化一直是业界积极探索和实践的方向，越来越多的公司使用组件化来构建项目，我们公司在组件化实践方向也有了一些实践，但目前还没有一个标准，这也是我们为什么要整理这个文档的目的，确定一下组件化的方案，为未来的复杂业务助力。
组件化带来的优势
首先组件化的一些优势是我们应用它的核心价值，那么都有哪些优势呢？大致总结如下：
1.加快项目编译速度，提高开发效率，因为模块可以独立编译、测试、打包和部署
2.提高组件的复用
3.避免了模块之间的交叉依赖，做到低耦合、高内聚
4.引用的第三方库代码统一管理，避免版本不统一，减少引入冗余库
组件化目标
首先设立一个目标，来保证我们后续不偏离方向，不能为了组件化而组件化，复杂的设计必定会造成大量的学习成本，反而会降低开发效率，其实我们设计组件化的初衷也是为了能更加简单化，而且目标促使我们价值观统一，大家朝一个方向努力，共同创造价值。 如下：
1.生成组件化模版项目，能够快速的迭代新项目 2.组件化脚手架，可定制化
组件化规范
1.代码尽可能的解耦
- 对项目进行模块拆分，模块分为两种类型，一种是功能组件模块，封装一些公共的方法服务等，作为依赖库对外提供；另一种是业务组件模块，专门处理业务逻辑等功能，这些业务组件模块最终负责组装APP。
2.每个组件都可单独运行
- 每个组件都是高度内聚的，是一个完整的整体
- 通过 Gradle脚本配置方式，进行不同环境切换
3.组件间通信
- 通过路由的方式进行通信（路由框架待选择）
4.规范组件生命周期
- 生命周期指的是组件在应用中存在的时间，组件是否可以做到按需、动态使用、因此就会涉及到组件加载、卸载等
5.严格限制公共基础组件的增长
- 随着开发不断进行，要注意不要往基础公共组件加入太多内容。而是应该减小体积！倘若是基础组件过于庞大，那么运行组件也是比较缓慢的
组件化常见问题以及解决方案
1.通信 通信这个需要考虑两个方面，一个是同进程之间，一个是跨进程之间，那么就会有两种解决方案如下： 同进程： 接口依赖调用 跨进程：github.com/iqiyi/Andro…Andromeda提供了接口式的组件间通信管理，包括同进程的本地接口调用和跨进程接口调用。
2.初始化
- developer.android.com/topic/libra… google官方
- github.com/bingoogolap… 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 组件化项目：github.com/VMadalin/an…
组件化架构图设计
以上设计图，遵循组件化规范。详细介绍请往下看。
模块介绍
1.业务组件这一层，主要是能否独立业务的组件，如登陆模块可以抽离出一个完整的组件，并可以打包出独立的app包。
2.功能组件 • Common：包含公共业务接口定义，数据模型，数据库相关。• 自定义View：一些特殊样式，或者组合使用的自定义View • 日志：日志框架组件，如logan • 推送：push消息等组件，独立于业务• 分享：分享SDK • 视频：视频相关功能组件• 即时通讯：聊天实时消息相关组件
3.Core基础层：
- 网络请求(采用 Retrofit+协程)
- 图片加载(策略模式，Glide 与 Picasso或者coil 之间可以切换)
- 基类 Adapter 的封装（支持 item动画、多布局item、下拉和加载更多、item点击事件）
- 通用的工具类，Kotlin版本的动态扩展（Context、Fragment、Activity、Service、Intent等）
- 协程封装
- 其他等等
4.BuildSrc + Composite Builds Module BuildSrc的运用更好的Gradle依赖关系管理，Composite Builds提升构建速度，编写自定义插件。且统一管理框架版本信息，防止组件之间框架依赖版本冲突问题
组件化脚手架介绍
首先说下为什么要设计脚手架，这个源于SpringBoot脚手架的灵感，因为组件化后，项目各个模块相对独立，如果我们开发新项目就会遇到各种各样的功能，且符合我们的实际场景需求，如： 咨询师没有数据库，而其他app都需要数据库存储。小猫大部分是离线处理，而ESA又都是后台处理，每个业务都有不同的特点，所以我们想做一个可定制化的组件化项目，而不是一成不变。 脚手架的开发也是我们设计的一个目标，设计如下：
此脚手架我们做的是在线的，傻瓜式操作，只需要在页面中选择已经配置好的模版，可定制如下：
- 包名
- 语言
- 最低兼容版本
- 架构选择
- 组件依赖
当然这个页面的设计还不够完善，没有体现可以依赖三方框架，这个我们也会在未来的设计中加入进去，结合我们公司实际的业务场景，来做到定制化生成。
讨论结论
目前待确认框架选型如下：
- 不使用单Activity+多Fragment架构（此点考虑到C端已经在用多Activity，且单Activity并没有更好的实践结果，所以保持原有架构）
- 数据库考虑升级为moshi，或者kotlin官方serialization，去除Gson逻辑，后续专门做专题讨论
- 网络层抛弃Rxjava方式，未来用okhttp+协程方式，后续专门做专题讨论
- 页面跳转依然适用Arouter
- 组件初始化目前有贤论大佬自开发方案和google官方或美团相关方案，待后续专门专题讨论
- gradle build方式更新为 kotlin dsl gradle
参考项目
github.com/hegaojian/J…github.com/goldze/MVVM…github.com/getActivity…github.com/android/sun…
