一、组件化分层

根据具体业务，功能，大致可以将项目拆分为以下三类组件：

1. 基础组件
这类组件完全独立，不依赖其他任何组件。变动频率极低，一般情况以maven方式集成
例如网络请求组件、文件下载组件、数据持久化组件等

2. 功能组件
这类组件会依赖一些基础组件，但是不会依赖同层的组件。变动频率较低
例如分享组件，它有网络请求，也会有文件的下载合存储的操作，因此会依赖网络请求、文件下载、数据持久化等组件

3. 业务组件
这类组件是由完整的项目拆分而来，有着具体的业务能力。变动频率较高
这类组件和其他两类组件最大的差别在于：它会使用其他组件的能力，也会使用基础组件和功能组件的能力。
因为变动频率较高，因此它有必要成为独立app运行，以提高开发调试的效率

备注：
这种分层，只是理论上的分层，目的是为了让整个项目条理清晰，便于分工。
在代码结构、组件配置上，它们没有任何的不同。

二、组件高内聚+组件间通信

它们俩是伴生关系，组件高内聚了，如果没有组件间通信方式，那么组件只是一个孤岛。而组件间通信，如果没有具体的组件来使用它，那么它也只是一个空中楼阁。

所谓高内聚，就是让程序尽可能在组件内执行，不和外界产生交集。
但是，在时机情况里，又无可避免的需要和其他组件产生交集，具体场景如下：

那么，怎么做？
以上这些场景，根据使用方式的不同，可以将处理方案可以划分为两类：隐形依赖、直接依赖

隐形依赖

组件暴露给外部的activity、fragment，使用方并不关心它具体的实现类，只要它是Activity、Fragment就够了，因此，它们能做到完全隐形，仅由路由字符串就可以实现能力暴露。

组件内：使用arouter+路由字符串完成注册
使用方：使用arouter+路由字符串实现跳转或获取实例对象。

直接依赖
高人云：有些时候，需要承认自己的不足，对于无能为力的情况，只有妥协。
对于场景3、4、5，暂时无法通过路由表完全隔离源代码，或者说使用源代码的性价比要高很多。
在这种情况下，就需要适当打破我们最初的目标——组件高内聚。

为了让打破变原则变得优雅一点，这里将实现方式设计如下：

结语
其实，编程界随处可见这种设计（高内聚+组件间通信），例如：

👀关注公众号：Android老皮！！！欢迎大家来找我探讨交流👀