利用CTMediator的组件化通过target-action操作。 先看下如何使用CTMediator的。
组件化2_调用讲解.png
组件化2调用顺序.png
相关连接可以查看 主要基于Mediator模式和Target-Action模式，中间采用了runtime来完成调用。这套组件化方案将远程调用和本地应用调用做了拆分，而且是有本地应用为远程调用提供服务。
两种调用方式:1.本地调用方式 2.远程调用方式
1.先说本地应用调用，本地组件A在某处调用[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}]向CTMediator
发起跨组件调用，CTMediator根据获得的target和action信息，通过objective-C的
runtime转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻
辑，完成需求。
2.在远程调用中，远程应用通过openURL的方式，由iOS系统根据info.plist里的scheme配置找到可以响应的URL的应用
3.组件化方案中的去model设计。如果组件间调用不对参数做去model化设计，就会导致业务形式上被组件化了，实质上依然没有被独立。 假设模块A和模块B之间采用model化的方案去调用，那么调用方法时传递的参数就会是一个对象如果对象不是一个面向接口的通用对象，那么mediator的参数处理就会非常复杂，因为要区分不同的对象类型。如果mediator不处理参数，直接将对象以范型的方式转交给模块B，那么模块B必然要包含对象类型的声明。假设对象声明放在模块A，那么B和A之间的组件化只是个形式主义。如果对象类型声明放在mediator，那么对于B而言，就不得不依赖mediator。但是，大家可以从上面的架构图中看到，对于响应请求的模块而言，依赖mediator并不是必要条件，因此这种依赖是完全不需要的，这种依赖的存在对于架构整体而言，是一种污染。
4.为什么使用category去model化以及。
每个mediator的category,每一个对应一个target，每个category里的方法对应这个target下所有可能的调用场景，这样调用者在包含mediator的时候，自动获得了所有可用的target-action。
5.target-action 是最适合的，因为动态调用在一般场景下都是有范围的，大多数是活动页需要动态调度，今天这个活动明天那个活动，所以产生动态动态调度的需求。我们在可能产生动态调度的action中审查当前action是否需要被动态调度，在常规调度中就没必要审查了。
6.审查流程
6.1 APP 启动时下载调度列表，或者定期下载调度列表，然后审查时检查当前action是否存在要被动态调度跳转的action，如果存在，则跳转到另一个action。
6.2 每一次达到新的action时，以action为参数调用API获知是否需要被跳转，如果需要被跳转，则API告知要跳转的action,然后再跳转到API指定的action。
在传no的情况下，target对象在初始化之后，跑完action就立刻释放了。如果action中调用了异步方法，这种情况就会导致接收不到异步方法的回调。
6.3所以当你要调用的target的这个action含有异步方法的时候，此时应该传YES。当异步回调结束你拿到异步回调的时候再把这个target给clean一下。
比如你要上传文件，你通过category传了文件地址、成功回调block、失败回调block这三个参数给target-action。target-action就会调用异步上传接口进行上传。上传完毕之后弹框，然后调用你之前传过来的block。
这种情况target-action需要知道上传组件上传完毕，它才能弹框，才能调用你给的block。如果shouldCacheTarget不是yes，action跑完上传接口，就直接退出了，target直接回收了。它就永远没有机会弹窗，也没有机会调用你给的block了。
接下来我们用代码来简单实现下:
代码上传至githup中
网友评论