以往经历的项目需要解决的问题：
一.直播间VC超两万行代码，解耦问题；目前存在问题如下：
1.所有子模块都是以属性的方式让vc持有
2.每个子模块加载处理完数据都通过代理往vc回调结果
3.子模块产生的UI事件（除了触发公共组件的功能）需要触发直播间vc其他子模块的逻辑，也往vc通过代理回调导入。
这三个种情形是造成目前直播间vc代码无限扩张的根源。
解决方案：采用面向协议编程的方式解耦，建立一个树状结构的component组件树。
1.父组件采用subComponent结构组合子组件模块，这样就不用每个子模块都声明一个属性。
2.每个子组件以协议的方式暴露给组件树中的其他组件，自己能完成的功能。
3.每个子组件通过parentComponentForProtocol与subComponentForProtocol可以找到组件树中任意指定协议的component组件。这样每个子组件即使需要跟直播间vc的其他组件模块通信，直接在自己内部完成不需要再往直播间VC回调任何代码。
4.由于每个组件是以协议的方式暴露自己的功能，这些协议完全可以抽象为一个基础框架pod库，这样就完美的解决了子组件间的依赖关系。
二.项目模块化中使用的TargetAction：(对比之下，作为模块解耦方案CTMediator有些问题值得讨论)
1）CTMediator使用runtime方式，动态生成类与方法selector导致类型不确定性。方法与传参完全依靠字符串与param字典来确定，本身可读性就很差，看的人一头雾水。
2）没法动态实现子模块路由嵌套与子路由的内存动态加载与动态释放的问题
3）https://juejin.cn/post/6844903711597133831
从作者的解决方案来看，都觉得麻烦。这个categoryPod不就是独立的功能组件模块提供的协议文件吗。那为什么不直接用使用protocol协议呢。
三.解决单利泛滥，单利没法回收
目前项目各个不同模块组件化（如登录模块，充值模块等等），都是单利的方式实现的；但是单利的问题的就是没法动态内存加载/释放。如果做成登录component，充值component作为整个app根节点的一个个的子component就可以实现，收到内存警告时，登录成功，或者充值完成。释放掉这些子component。
四.单元测试更加方便
五.代码结构清晰后，造成的BUG将大大降低
