前言
App开发的场景：很多时候，是多人协作开发，组合使用。
在组件化的情境下，我们需要特别注意解耦和动态
似乎搞研发的，哪里都是解耦、聚合、动态。说来说去真的就是这些。
所谓解耦
每个模块在开发阶段，只受到所在模块影响，单一模块的更快，不会影响到其他模块。
所谓动态
模块的加载是随意的。不受布局，外部因素影响。像一块积木。
分发的理念
很多时候，业务开发的功能组合，是Activity和Fragment组合、Fragment和Fragment组合、View和View组合、View和Fragment组合、View和Activity组合。
这里我们以Activity和Fragment组合为例。
为什么选它呢？因为View有关的组合，改动较多，third组件库又怎么办。改的消耗太大。所以，View我是随意的，该怎么用怎么用Activity是window嘛，Activity和Fragment是常用组合Fragment和Fragment组合的套路其实差不多。先看这个
Activity主体：这里是生命周期➕一些必要的回调函数封装层：➕一层封装调用Fragment层：实现了封装层的interface分发的基本原则
➕一个生命周期封装层。通过封装层进行生命周期函数回调的派发。
这里我们依赖的是抽象接口！高层函数不依赖底层模块，而是依赖其抽象！底层模块尽量使用抽象或者接口定义。变量的类型尽量是抽象类或者接口。子类必须实现父类中的所有方法。
小结
架构或者编码讲究的是职责分离。
通过依赖倒置的设计方案解放每个Module对宿主Activity/Fragment在布局上的依赖。
推荐使用Activity/Fragment进行分发。
View胜在粒度小，但这也带来了更多的module，以及第三方view适配的问题。实际上工作量是会放大。module数量很会变多。划不来。综合考虑Fragment的粒度比较合适，宿主Activity+功能Fragment的形式较为合理
