iOS 组件化

喜马拉雅企业版组件化记录

组件化的作用：

实现模块的解耦合，进而独立成一个个小业务开发，
避免了大型App编译速度慢的问题，提高团队的开发效率

组件化过程：

1. 划分基础组件、通用业务组件、业务组件，通用基类（Model）的下沉
2. 将App的基础组件Http、Log、、CommonUI抽离成一个个独立的pod库
    1. 基础组件不能出现耦合
3. 逐步剥离通用业务组件
    1. 通用业务组件可以依赖基础组件
    2. 通用业务组件之间不能出现耦合
4. 逐步剥离业务组件
5. 实现业务独立开发，自动化打包

业界采用

组件化方案
 1. URL注册回调
    缺点：
    1. 难以携带Objc对象
    2. 长度有限
    3. 协议会注册很多，内存问题

2. Protocol注册调用
    缺点：
    1. 需要独立出单独的接口层并抽成pod，否则互相调用的模块间会出现耦合
3.  用Category分离用字典传参数
    缺点
    1. 需要经历method参数->字典->调用参数的过程
    2. 需要在Category出现硬编码

好的组件化方案具有一下特点：

1. 支持模块内注册
2. 支持URL scheme注册,并可以携带参数
3. 支持App事件的分发
4. 模块的接口可以独立维护，比如对于模块A：模块A与模块A的接口分别以2个独立的pod库
5. 在不支持或未实现相应service的时候能够给与提示Alert等

开源方案分析

BeeHive
1. 模块的注册
    1. 支持模块加载的优先级
    2. 支持模块的一步加载
    3. 支持注解、静态、动态注册
2. App事件的分发（BHModuleManager）
    1. 支持将App的事件传给各个模块
3. 模块间调用 （BHServiceManager）
    1. 使用protocol调用
4. URL调用 （BHRouter）
    1. 采用注册机制
    2. 支持相应block回调
思考：是否需要把模块间的调用和URL调用分为两个类管理？

模仿BeeHive写的组件化方案

1. Context，用于统一存储App的状态

sdadf fd

s	1