Android 组件化框架
01.传统APP架构图
- 传统APP架构图
- 如图所示，从网上摘来的……
- 存在的问题
- 普遍使用的 Android APP 技术架构，往往是在一个界面中存在大量的业务逻辑，而业务逻辑中充斥着各种网络请求、数据操作等行为，整个项目中也没有模块的概念，只有简单的以业务逻辑划分的文件夹，并且业务之间也是直接相互调用、高度耦合在一起的。单一工程模型下的业务关系，总的来说就是：你中有我，我中有你，相互依赖，无法分离。如下图：
02.组件化需要考虑问题
- 考虑的问题
- 分而治之，并行开发，一切皆组件。要实现组件化，无论采用什么样的技术方式，需要考虑以下七个方面问题：
- 代码解耦。
- 如何将一个庞大的工程分成有机的整体？这个需要一步步来了！
- 对已存在的项目进行模块拆分，模块分为两种类型，一种是功能组件模块，封装一些公共的方法服务等，作为依赖库对外提供；另一种是业务组件模块，专门处理业务逻辑等功能，这些业务组件模块最终负责组装APP。
- 组件单独运行。
- 因为每个组件都是高度内聚的，是一个完整的整体，如何让其单独运行和调试？
- 通过 Gradle脚本配置方式，进行不同环境切换，我自己操作是添加一个boolean值的开关。比如只需要把 Apply plugin: ‘com.android.library’ 切换成Apply plugin: ‘com.android.application’ 就可以独立运行呢！
- 需要注意：当切换到application独立运行时，需要在AndroidManifest清单文件上进行设置，因为一个单独调试需要有一个入口的Activity。
- 组件间通信。
- 由于每个组件具体实现细节都互相不了解，但每个组件都需要给其他调用方提供服务，那么主项目与组件、组件与组件之间如何通信就变成关键？
- 这个我是直接用阿里开源的路由框架，当然你可以根据需要选择其他大厂的开源路由库。引用阿里的ARouter框架，通过注解方式进行页面跳转。
- 组件生命周期。
- 这里的生命周期指的是组件在应用中存在的时间，组件是否可以做到按需、动态使用、因此就会涉及到组件加载、卸载等管理问题。
- 集成调试。
- 在开发阶段如何做到按需编译组件？一次调试中可能有一两个组件参与集成，这样编译时间就会大大降低，提高开发效率。
- 代码隔离。
- 组件之间的交互如果还是直接引用的话，那么组件之间根本没有做到解耦，如何从根本上避免组件之间的直接引用？目前做法是主项目和业务组件都会依赖公共基础组件库，业务组件通过路由服务依赖库按需进行查找，用于不同组件之间的通信。
- 告别结构臃肿，让各个业务变得相对独立，业务组件在组件模式下可以独立开发，而在集成模式下又可以变为AAR包集成到“APP壳工程”中，组成一个完整功能的 APP。
- 代码解耦。
03.组件化架构图
- 组件化架构图
- 业务组件之间是独立的，互相没有关联，这些业务组件在集成模式下是一个个 Library，被 APP 壳工程所依赖，组成一个具有完整业务功能的 APP 应用，但是在组件开发模式下，业务组件又变成了一个个Application，它们可以独立开发和调试，由于在组件开发模式下，业务组件们的代码量相比于完整的项目差了很远，因此在运行时可以显著减少编译时间。
04.组件通信是通过路由转发
- 传统以前工程下模块
- 记得刚开始进入Android开发工作时，只有一个app主工程，后期几乎所有的需求都写在这个app主工程里面。只有简单的以业务逻辑划分的文件夹，并且业务之间也是直接相互调用、高度耦合在一起的。
- 导致后期改项目为组件化的时候十分痛苦，不同模块之间的业务逻辑实在关联太多，但还是没办法，于是目录4步骤一步步实践。终极目标是，告别结构臃肿，让各个业务变得相对独立，业务组件在组件模式下可以独立开发。
- 组件化模式下如何通信
- 这是组件化工程模型下的业务关系，业务之间将不再直接引用和依赖，而是通过“路由”这样一个中转站间接产生联系。在这个开源项目中，我使用的阿里开源的路由框架。
05.业务组件的生命周期
- 按照理想状态的来看待的话
- 各个业务组件之间没有任何依赖关系，这时我们可以把每个独立的业务组件看成一个可运行的app，所以业务组件的生命周期和应与独立的app保持一致。