WX20200424-185221.png
优点
- 业务分层、解耦，使代码变得可维护；
- 有效的拆分、组织日益庞大的工程代码，使工程目录变得可维护；
- 便于各业务功能拆分、抽离，实现真正的功能复用；
- 业务隔离，跨团队开发代码控制和版本风险控制的实现；
- 模块化对代码的封装性、合理性都有一定的要求，提升开发同学的设计能力；
- 在维护好各级组件的情况下，随意组合满足不同客户需求；（只需要将之前的多个业务组件模块在新的主App中进行组装即可快速迭代出下一个全新App）
要求
- 需要一定编码基础
- 公用的工具类最好统一管理，节省资源，避免不必要的功能大同小异的类
- 需要合理拆分模块，规划模块，以及相关之间的业务关系
组件化解耦
- 分层
基础功能组件：按功能分库，不涉及产品业务需求，跟库Library类似，通过良好的接口拱上层业务组件调用；不写入产品定制逻辑，通过扩展接口完成定制；
基础UI组件：各个业务模块依赖使用，但需要保持好定制扩展的设计
业务组件：业务功能间相对独立，相互间没有Model共享的依赖；业务之间的页面调用只能通过UIBus进行跳转；业务之间的逻辑Action调用只能通过服务提供；
- 中间件
方案比较
Router、 CTMediator
Router的缺点：
- 在组件化的实施过程中，注册URL并不是充分必要条件。组件是不需要向组件管理器注册URL的，注册了URL之后，会造成不必要的内存常驻。
- 维护成本，维护路由。各种路由的添加，以及添加时候的不规范会导致产生一些过时不用的，以及功能重复的路由的产生
- 参数的传递，个人认为这个到还好，毕竟MGJRouter等其他三方路由方案都已经支持传参数，以字典携带需要的参数传递
Router的优点：
- 方便统一化处理，由服务器统一配置，做到安卓和IOS的统一。
- 跳转的时候不用依赖具体的目标类
- 从外部（web或者其它app，推送等）打开App指定页面。
CTMediator的优点：
- 调用时，区分了本地应用调用和远程应用调用。本地应用调用为远程应用调用提供服务。组件仅通过Action暴露可调用接口，模块与模块之间的接口被固化在了Target-Action这一层，避免了实施组件化的改造过程中，对Business的侵入，同时也提高了组件化接口的可维护性。
- 由于是利用Runtime，不需要注册URL，不需要常驻内存。个人觉得是这个是主要优点
CTMediator的缺点：
- 安卓 IOS 统一较困难？由于没有进一步使用不太清楚 欢迎补充。
一些别人写Router 地址:
