基于CTMediator的组件化实践

为什么要组件化

统一编码规范

业务模块组件化

开发环境动态切换

模块可复用

UI模块双向依赖明显

---

怎么传递参数

采用字典。会有缺点

妥协方案：公共的model也建立pod库

---

组件化主要有三种方案：

1. URLRouter。缺点：需要常驻字典维持这个列表。oc一般在load方法来注册这些url-block；swift没有load方法。需要常驻内存，并且影响启动速度，RouterManager需要import所有需要的vc头文件。

2. Target-Action。代表是CTMediator。 缺点： 采用了runtime，swift自身是不支持rumtime的，以及少量的硬编码。

3. Protocal-Class。 代表是BeeHive。总体来说还是最专业的方案。缺点是对代码侵入性高；采用一个全局字典的变量，key为Protocal的字符串，value是class；需要在app启动（swift工程）添加注册的方法。缺点同URLRouter，优点在于没有硬编码。

---

技术要点：

1.  资源文件比如图片。有的图片是多个模块公用，有的图片只在一个模块使用，如何使图片更好的支持组件化？

2. 有些model是在单个模块使用，有的是多个模块使用，如何规划？

3. 对AppDelegate瘦身，需要对事件进行封装。

组件化开发过程中缺点：

Module内对修改要clean build后生效，太耗时间。感觉项目在相对稳定后可以引入组建化。

---

组件化中疑难点：

1. swift 调用 oc的库：新建一个swift类对oc的接口进行封装。

2. oc调用swift的。

3.  不同组件中的资源重复。

最好是分配给各个组件，会有一定的浪费； 然后可以脚本去掉重复的图片。或者是iconFont。

4. oc和swift库混编

5. 动态切换环境：如首页双击四次，弹框，选择后，重启app；

---

组件分层：

最底层：基础组件： 持久化，导航栏，log日志，网络，第三方库sdk，文件服务，分类

中间： 功能组件： 地图服务，数据管理，城市管理，广告管理

上层： 业务模块组件： 业务模块解耦

---

建议：

少用宏

不出现common组件

使用storyboard：界面元素越多的情况下优势越明显。