问题
每个App都不可避免有一两个复杂的页面，首页啦、主要功能的detail页啦都跑不掉又臭又长。而当海外成为理所应当拓展的市场时，解耦复杂页面、在页面中按需加入功能就是一个刚需了。
具体来说，解耦有几个方面：接口/功能的解耦、View层面（特别是id）的解耦、生命周期传递。
通用解决
- 对于接口和功能，使用IOC或者Event方式。每个业务有自己的api module（声明接口和Event，一直打入App）和biz module（实现接口和具体业务逻辑，按需打入）
- 对于生命周期，方便就用fragment，不方便就用FragmentLifecycleCallbacks
基于RecyclerView的情况
如果是基于RecyclerView的复杂页面，而且插拔粒度是item级别，那么仅需要一系列ViewHolder工厂类。
public interface ViewHolderFactory<T> {
boolean canHandle(T model);
ViewHolder create(T model);
}作为mediator的Adapter（module：core）负责：
- 持有所有可用Factory实例（可用通过注册去掉core对于biz的依赖）
- 匹配数据极其对应的Factory实例
- 路由onCreateViewHolder，当然这时ViewHolder肯定是要有必要的统一的绑定接口
上面这种情况，并没有什么太大的问题，因为：
- View直接的交互为0，不存在id的依赖
- 所有的接口都可以简化为ViewHolder+Factory
真正的问题
真正的问题是复杂的Linear页面，这时，没有现成的mediator做View管理，比较棘手。
仿照RecyclerView
适合有固定坑位的页面，比如说股票详情页，页面大概由固定大小的几部分构成。那么，可以为每个坑位定义一个ViewType。
不同的使用方声明好ViewType到xml的映射，直接用List<ViewType>+ Adapter方式做页面的排布。如果有生命周期强需求，可以直接返回一个Fragment（反正什么ViewHolder都是自己做主）。
这时候module的依赖是：使用方-> biz … -> core。按需打入的方案是写死到使用方module中，每个使用方明确整体布局和所需biz。
优点是直观、简单
缺点就是会出现同一个布局（坑位）重复定义，打包不够灵活（每个不同使用方都有固定的功能）
改进一点点
可以在core中布置好所有坑位，每个使用方只是一个配置文件，如果没有打入某个biz，其坑位直接GONE掉。
优点是更加简单，单点修改
缺点是core中占坑布局难于维护，页面结构不够用灵活（所有需求方都长得一样）
基于Fragment
很多页面并没有预知的固定坑位，比如直播页面，View似乎是随性摆到页面上的。
这时可以使用一个ConstraintLayout（match_parent的）作为Fragment的container，所有的biz module都声明一个FragmentFactory，mediator负责将fragment加入到container中（add）。所有View、id都放到各自api module中，由此各业务可以自由相互依赖。
View的依赖由每个Fragment在onActivityCreated中加上依赖。
优点是自由度大
缺点是布局复杂，相当于有一个Canvas，大家随便画，容易出现业务之间相互覆盖的情况
试图解决大Canvas问题
其实就是在解决ViewGroup layoutChindren时面临的问题，方法也可以是类似的。让每个module有自己的大小、位置、优先级等属性，mediator 对其进行layout，如果遇到冲突，优先排列优先级高的module。