CTMediator的Swift应用

如果你的工程是采用CTMediator方案做的组件化，看完本文以后，你就可以做到渐进式地迁移到Swift了。 CTMediator支持所有情况的调用，具体可以看文后总结。你的工程可以让Swift组件和Objective-C组件通过CTMediator混合调用 也就是说：以后再开新的组件，可以直接用Swift来写，旧有代码不会收到任何影响。

这篇文章适用最低支持iOS 8的工程，且必须使用Cocoapods 1.6.0.beta.1以上的版本

本文提及的框架：CTMediator

相关文章：《iOS应用架构谈 组件化方案》 《在现有工程中实施基于CTMediator的组件化方案》

Swift调度Demo工程：SwfitDemo，Objective-C调度Demo工程：ModulizedMainProject

跑Demo前先添加私有仓库：

pod repo add PrivatePods https://github.com/ModulizationDemo/PrivatePods.git

然后进入对应工程pod update --verbose即可。

最近我惊喜地发现，几天前（8月17号）Cocoapods在1.6.0.beta.1版提供了--use-modular-headers参数，它可以大大简化依赖Objective-C Pod的Swift Pod的发版流程。

于是我打算把我过去这些为Objective-C的工程写的框架全部用Swift再写一遍。目前已经完成的只有SwiftHandyFrame。（这个工具在我自己的业余项目里用了一圈，感觉很不错，达到了我之前设想的目的。）

然而以上开源工程中，有一个从设计思想上就非常依赖Objective-C的框架是CTMediator。

我尝试去思考一个新的、符合Swift且优雅的组件化方案，但并没有找到比CTMediator更好或一样好的方案。于是我探索尝试了一下，也填了一些坑。最终我发现CTMediator方案本身虽然很不Swift，但即使是在Swift工程中，CTMediator依旧是一个很优雅的组件化方案。因为：

1. CTMediator是一套不需要随工程迭代修改的代码，它也不与任何业务产生交互，引入之后对Swift工程开发的影响为0
2. Swift工程可以使用Extension替代原先Objective-C工程的Category并能够正常发版。因此在方案实施全程都可以做到纯Swift编码，可以完全忘记CTMediator是Objective-C工程这回事儿
3. 新版的CocoaPods对依赖Objective-C Pod的Swift Pod十分友好，在Swift Pod中引入CTMediator可以做到完全无感，你即使不会写Objective-C，也不影响你来使用CTMediator方案
4. Swift工程也可以使用Objective-C工程历史遗留的Category和Target-Action来完成调度，因此Objective-C开发团队可以使用旧有代码渐进地实施Swift迁移，而不必担心引入新的bug。

综合以上几点，可以给到2个结论：

1. CTMediator方案是可以优雅地应用在Swift工程中的
2. 凡是过去应用CTMediator组件化方案的Objective-C团队都可以做到无痛迁移Swift

前面的部分论证了结论1。

文章接下来的内容有两个目的：

1. 说明结论2。因此之前就采用CTMediator组件化方案的Objective-C团队们，你们看完这篇文章之后，就可以放心地让团队往Swift方向迁移了。
2. 一直在做Swift开发的团队们，你们也可以放心使用CTMediator方案了。它不仅更加强大，同时CTMediator是Objective-C工程这一点对Swift工程（无论是现有工程还是新工程）的影响为0

1. 为Swift响应者组件提供Target-Action
2. 为方便调度给CTMediator写Extension
3. Swift响应者工程、Swift调度者工程、Extension工程的发版
4. Swift调用者通过Extension调度Objective-C响应者
5. 总结: Swift组件与Objective-C组件互相调用的全部8种情况，及其对策

---

1. 为Swift响应者组件提供Target-Action

Target-Action 的目的

CTMediator方案的表象是通过runtime调度Target-Action，但是CTMediator方案的本质是在不需要动业务代码的情况下，完成调度。

所以在提供Target-Action的时候，我们一般都选择让Action把对应的业务做完，如果有调用者需要补充逻辑的，通过closure给到。而不是返回一个什么对象给调用者，然后调用者再去做逻辑。

举个例子：

A需要展示B页面。你可以选择：

1. 让B的Target-Action直接返回一个UIViewController，然后A去push或者present。
2. 让B的Target-Action直接完成页面展示的操作，具体是push还是present，由A传过来的参数决定。

一个好的Target-Action倾向于2。因为这种做法对于A业务来说，留下的足迹更小，踏雪无痕是我们追求的目标。

Swift工程声明Target-Action的注意事项

1. Target对象必须要继承自NSObject
2. Action方法必须带@objc前缀
3. Action方法第一个参数不能有Argument Label

一个Swift版的Target-Action如下：

class Target_A: NSObject { // 必须要继承自NSObject

    // 正确的Action声明
    @objc func Action_viewController(_ params:[AnyHashable:Any]?) -> UIViewController {

    }

    // 错误的Action声明：没有带@objc前缀
    func Action_viewController(_ params:[AnyHashable:Any]?) -> UIViewController {

    }

    // 错误的Action声明：方法带上了Argument Label
    func Action_viewController(viewControllerParams params:[AnyHashable:Any]?) -> UIViewController {

    }

    // 错误的Action声明：方法带上了Argument Label
    func Action_viewController(params:[AnyHashable:Any]?) -> UIViewController {

    }

}

params 的类型也可以为NSDictionary，所以这么写也是可以的：

    func Action_viewController(params:NSDictionary) -> UIViewController {

    }

Swift工程实现Action时的注意事项

这里要注意的点在于如何处理block或closure。主要原因是如果调用者通过Category来发起调用，那么就只能传递block。如果是通过Extension来发起调用，那么就只能传递closure。至于调用者是Swift还是Objective-C倒是无所谓的。

• 我们先看调用者是通过Category发起的调用，然后响应者是Swift的情况

由于Category中只能传递block，所以此时你的Action获得了一个block。在swift响应者中，这个Action就要这么写：

    @objc func Action_viewController(_ params:[AnyHashable:Any]?) -> UIViewController {

        if let actionParams = params {
            let block = actionParams["callback"]

            // 转换一下
            typealias CallbackType = @convention(block) (String) -> Void
            let blockPtr = UnsafeRawPointer(Unmanaged<AnyObject>.passUnretained(block as AnyObject).toOpaque())
            let callback = unsafeBitCast(blockPtr, to: CallbackType.self)

            // 此时block就变成了closure，就可以正常调用了
            callback("success") 
        }

        let aViewController = ViewController()
        return aViewController
    }

• 我们再看调用者通过Extension发起的调用，然后响应者是Swift的情况

这种情况就很自然了，因为两边都是Swift环境（对的，我们完全可以忽略CTMediator是一个Objective-C组件的事实），所以可以直接使用：

    @objc func Action_viewController(_ params:[AnyHashable:Any]?) -> UIViewController {

        if let actionParams = params {
            if let callback = actionParams["callback"] as? (String) -> Void {
                callback("success")
            }
        }

        let aViewController = ViewController()
        return aViewController

    }

所以如果你的响应者需要同时服务来自Category的调度和Extension的调度，而且需要处理block或closure的话，你就需要在Category中或Extension中给到一个参数，来决定你如何实现这个Action。不过一般来说这种情况很少，为了同一个调度又写Category又写Extension基本上是不太可能的。

2. 为方便调度给CTMediator写Extension

Extension 的目的

理论上我们可以直接使用CTMediator来完成调度。但是这么做的话，写调用代码的工程师就会产生这样的迷惑：“为了调度成功，我应该给到什么target，什么action，以及参数都要传哪些？”

// 如果直接这么使用CTMediator，调用工程师需要去查文档获知自己这次调用对应的target-action是什么，参数是什么，module_name是什么。
    CTMediator.sharedInstance.performTarget("A",action: "viewController", params: ["name":"casa", "age":18, kCTMediatorParamsKeySwiftTargetModuleName:"module_name"], shouldCacheTarget: false)

所以为了不让写代码的工程师迷惑，我们提供Extension来描述一个调用应该传什么样的参数。在Extension的实现中，我们写入Target、Action以及ModuleName，这样工程师就不必迷惑了。

// extension CTMediator
    public func A_show(callback:@escaping (String) -> Void) -> UIViewController?

// 给CTMediator写了extension之后，调用工程师拿到方法，按照方法的参数列表给到参数就可以了，不必去考虑对应的target-action是什么、参数是什么、module_name是什么了。
    let acontroller = CTMediator.sharedInstance().A_show { (result) in
        print(result)
    }

写Extension的注意事项

1. 写Extension的人需要知道响应者的module名，并且在传入的参数字典中给到，例如：[kCTMediatorParamsKeySwiftTargetModuleName:"module_name"]，这是Swift与Objective-C不同的地方。如果响应者是Swift，不给到Module名的话，runtime是调度不到响应者target-action的。如果是Objective-C的响应者，这个就可以省略了。
2. cocoapods发版的时候要带--use-modular-headers，因为这个组件依赖了CTMediator，它是Objective-C的工程。--use-modular-headers这个参数在Cocoapods 1.6.0.beta.1以上的版本才有。
3. 如果Extension里的某个方法要被Objective-C使用，那需要带上前缀@objc

一个完整可行的Extension是这样的：

import CTMediator

extension CTMediator {
    // 如果这个方法也要给Objective-C工程调用，就需要加上@objc
    @objc public func A_show(callback:@escaping (String) -> Void) -> UIViewController? {
        let params = [
            "callback":callback,
            kCTMediatorParamsKeySwiftTargetModuleName:"A_swift" // 需要给到module名
            ] as [AnyHashable : Any]
        if let viewController = self.performTarget("A", action: "viewController", params: params, shouldCacheTarget: false) as? UIViewController {
            return viewController
        }
        return nil
    }
}

它的发版命令是这样的：

// 带上--use-modular-headers，Cocoapods 1.6.0.beta.1以上支持
pod repo push Your_Repository Your_Podspec_file.podspec --verbose --allow-warnings --use-libraries --use-modular-headers

3. Swift响应者工程、Swift调度者工程、Extension工程的发版

其实跟之前私有pod的发版流程一模一样，只是如果你的Swift工程依赖了Objective-C工程的话，你多带一个--use-modular-headers参数而已。

4. Swift调用者通过Extension调度Objective-C响应者

这种情况下要注意的其实还是只有block和closure之间的转化，Extension需要将Swift的Closure转化成Objective-C的block对象之后再传递，完整的Extension示例如下：

extension CTMediator {
    public func A_showObjc(callback:@escaping (String) -> Void) -> UIViewController? {

        // 将closure类型转化为block类型
        let callbackBlock = callback as @convention(block) (String) -> Void
        let callbackBlockObject = unsafeBitCast(callbackBlock, to: AnyObject.self)

        // 转化完毕就可以放入params中传递了
        let params = ["callback":callbackBlockObject] as [AnyHashable:Any]

        if let viewController = self.performTarget("A", action: "viewController", params: params, shouldCacheTarget: false) as? UIViewController {
            return viewController
        }
        return nil
    }
}

对应的响应者Target-Action如下：

- (UIViewController *)Action_viewController:(NSDictionary *)params
{
    typedef void (^CallbackType)(NSString *);
    CallbackType callback = params[@"callback"];
    if (callback) {
        callback(@"success");
    }
    AViewController *viewController = [[AViewController alloc] init];
    return viewController;
}

这样就能保证调用成功。

5. 总结: Swift组件与Objective-C组件互相调用的全部8种情况，及其对策

其实如果你的工程是Swift调用者、Swift响应者的情况，那么应用CTMediator就一点问题都没有。

对于Objective-C的开发团队来说，如果开始渐进地将工程Swift化，那么就需要分各种情况去处理block和closure转化的问题。在这里我把可能出现的所有情况及其处理方法总结如下：

1 Swift调用者 + Extension + Swift响应者

1. Extension中给到的params需要带有kCTMediatorParamsKeySwiftTargetModuleNamekey来给到target所在module的名字
2. Extension中不需要针对closure做任何转化
3. 响应者target-action跟正常情况一样写
4. 响应者action方法首参数不要带Argument Label，用_

2 Swift调用者 + Extension + Objective-C响应者

1. Extension中给到的params不需要带kCTMediatorParamsKeySwiftTargetModuleNamekey
2. Extension中需要将closure转化成block对象之后再放入params传过去
3. 响应者的Target-Action跟正常情况一样写

3 Swift调用者 + Category + Swift响应者

1. Category中给到的params需要带有kCTMediatorParamsKeySwiftTargetModuleNamekey来给到target所在module的名字
2. Category中不需要针对block做任何转化
3. 响应者的Target-Action需要将block转化成closure
4. 响应者action方法首参数不要带Argument Label，用_

4 Swift调用者 + Category + Objective-C响应者

1. Category中给到的params不需要带kCTMediatorParamsKeySwiftTargetModuleNamekey
2. Category中不需要针对block做任何转化
3. 响应者的Target-Action跟正常情况一样写

5 Objective-C调用者 + Category + Objective-C响应者

1. Category中给到的params不需要带kCTMediatorParamsKeySwiftTargetModuleNamekey
2. Category中不需要针对block做任何转化
3. 响应者的Target-Action跟正常情况一样写

6 Objective-C调用者 + Category + Swift响应者

1. Category中给到的params需要带有kCTMediatorParamsKeySwiftTargetModuleNamekey来给到target所在module的名字
2. Category中不需要针对block做任何转化
3. 响应者的Target-Action需要将block转化成closure
4. 响应者action方法首参数不要带Argument Label，用_

7 Objective-C调用者 + Extension + Objective-C响应者

1. Extension中给到的params不需要带kCTMediatorParamsKeySwiftTargetModuleNamekey
2. Extension中需要将closure转化成block对象之后再放入params传过去
3. Extension中的方法需要带前缀@objc
4. 响应者的Target-Action跟正常情况一样写

8 Objective-C调用者 + Extension + Swift响应者

1. Extension中给到的params需要带有kCTMediatorParamsKeySwiftTargetModuleNamekey来给到target所在module的名字
2. Extension中不需要针对closure做任何转化
3. Extension中的方法需要带前缀@objc
4. 响应者target-action跟正常情况一样写
5. 响应者action方法首参数不要带Argument Label，用_

最后给到示例工程：

Objective-C为调用者：ModulizedMainProject

Swift为调用者：SwfitDemo

使用前先添加私有仓库：

pod repo add PrivatePods https://github.com/ModulizationDemo/PrivatePods.git

然后进入对应工程pod update --verbose即可。

关于CTMediator还有什么内容我没讲，或者没讲清楚的，再或者你针对CTMediator方案有任何问题的，都可以在文章下方评论区向我提问。

            </div>