简单来说: 一个模块对应一个 Mediator的分类 ,一个分类对应一个target,一个target可以包含多个action
一、要实现什么效果:
说一下场景,有一个模块A ,包括两个大页面,我要实现从APP某个页面跳转到模块A中的这两个页面并传值
我尝试去思考一个新的、符合Swift且优雅的组件化方案，但并没有找到比CTMediator更好或一样好的方案。于是我探索尝试了一下，也填了一些坑。最终我发现CTMediator方案本身虽然很不Swift，但即使是在Swift工程中，CTMediator依旧是一个很优雅的组件化方案。因为：
- CTMediator是一套不需要随工程迭代修改的代码，它也不与任何业务产生交互，引入之后对Swift工程开发的影响为0
- Swift工程可以使用Extension替代原先Objective-C工程的Category并能够正常发版。因此在方案实施全程都可以做到纯Swift编码，可以完全忘记CTMediator是Objective-C工程这回事儿
- 新版的CocoaPods对依赖Objective-C Pod的Swift Pod十分友好，在Swift Pod中引入CTMediator可以做到完全无感，你即使不会写Objective-C，也不影响你来使用CTMediator方案
- Swift工程也可以使用Objective-C工程历史遗留的Category和Target-Action来完成调度，因此Objective-C开发团队可以使用旧有代码渐进地实施Swift迁移，而不必担心引入新的bug。
综合以上几点，可以给到2个结论：
- CTMediator方案是可以优雅地应用在Swift工程中的
- 凡是过去应用CTMediator组件化方案的Objective-C团队都可以做到无痛迁移Swift
pods 库制作流程
pod lib create xxx 编辑podspec文件
添加需要制作库的代码文件和资源文件
pod installl 本地安装测试
gitlab 建立私有仓库 上传到私有库
git add .
git commit -am "xxx"
git push
git tag xxx
git push --tags
pod lib lint 本地验证
pod spec lint 远程验证
推送到私有索引库 pod repo push TDMasterSpec xxx.podspec --allow-warnings
