戴铭（iOS开发课）读书笔记：04章节-架构设计

原文链接：项目大了人员多了，架构怎么设计更合理？

---

03 章节 项目大了人员多了，架构怎么设计更合理？

随着业务需求量和团队的规模达到一定量级后，任何一个 APP 都需要考虑架构设计的合理性。

先思考，再动手。

戴铭老师在文中先抛出一种组件化划分模块粒度的原则：SOLID 原则

SOLID 原则

然后介绍了他心目中的好架构：CTMediator。
最后分享了在CTMediator的基础上扩展的案例：案例。

戴铭老师手绘图

这个案例在中介者架构的基础上，增加了对中间件、状态机、观察者、工厂模式的支持。同时支持了链式调用。有兴趣的朋友可以去阅读老师的源码。

---

我个人对于项目架构的理解比较简单，首先是代码模块的解偶和拆分，其次是模块间的通信。
戴铭老师的原文中，重点介绍的第二部分并推荐使用CTMediator的方式。
那么接下来，我先简单介绍一下代码模块的拆分，然后回归代码介绍一下CTMediator。

1 代码模块拆分

我接触到的代码模块的拆分有三种方式：静态库、动态库和远程私有库。

• 静态库 .a和.framework
• 动态库 .dylib和.framework
  区别：
  1 静态库链接时，静态库会被完整的复制到可执行文件中，被多次使用就有多份冗余拷贝
  2 系统动态库链接时不复制，程序运行时由系统动态加载到内存，供系统调用。系统只加载一次，多个程序共用，节省内存。
• 远程私有库 pod

1 静态库创建：

一共4种： DEBUG（真机，模拟），RELEASE（真机，模拟）

1 创建静态库

2 添加头文件，在Subpath处修改头文件路径

3 静态库分为真机和模拟器: lipo -info xxxx.a

• 真机结构是armv7 arm64
• 模拟器结构是x86_64

4 将真机和模拟器进行合并

lipo -create xxxx1.a xxxx2.a -output test.a

最后使用合并后的test.a文件。

5 将静态库的include-头文件，和.a文件（合并后的test.a文件）拖入真实项目中

image.png

注意1: 链接文件，如果在静态库中有分类文件。

-ObjC 链接所有OC文件
-all_load 链接所有文件
-force_load 链接.a路径

注意2：如果静态库中有xib文件，需要另行处理。

2 动态库创建：

1 创建动态库

2 头文件处理

3 将.framework直接拖入工程中， 但是直接运行会报错，因为苹果审核机制导致动态库失去了动态性，所以找不到映射关系，需要手动导入

4 手动copy

5 动态库真机和模拟器合并（脚本合并）
需要先分别生成动态库的真机和模拟器环境的.framework（各运行一遍）
然后再加入脚本，再运行一遍（真机和模拟环境随便选）
脚本代码大家自行百度一下。^ ^

6 动态库编译成静态库，这种方式就不用在项目中添加映射（copy file 第4步）

3 远程私有库：

这种方式是我们常用的方式，网上的资料也非常多，我这里把大概的步骤整理一下。具体遇到的问题还需要大家自己解决。最后的成果就是把项目中独立的业务模块抽离成pod的形式，在主项目中通过pod install进行安装。

1 建立本地私有库 pod lib create 'name'
2 在码云创建于本地私有库同名的私有项目
3 把本地私有库的文件提交到远程
    3.1 在本地私有库目录下，提交文件 git add.
    3.2 初始化 git commit -m '提交文件'
    3.3 关联到远程 git remote add origin xxx(网址)
    3.4 提交到远程 git push origin master -f 强制提交
    3.5 提交标签 git tag 0.1.0(这里与spec文件中的version相同)    -> git push
4 配置本地私有库的spec文件
    填写homepage、source等
    PS: 填写完成之后记得提交到项目远程
5 把spec文件提交到远程索引库（自己创建的库，里面只存放.spec文件）
    5.1 查看本地repo：pod repo
    5.2 把自己创建的索引库提交：pod repo add NAME xxx (xxx 表示项目地址，NAME是你的库名)   
    5.3 把本地私有库的spec文件提交到远程私有库：
        pod repo push NAME Utils.spec —allow-warnings (有时验证不通过需要忽略警告)
    5.4 或者手动将spec文件放入自己创建的远程索引库文件夹中

PS: pod lib lint 验证spec文件（这里经常会出错，需要对应处理）

2 模块间通信

1 路由

之前项目中一直使用的是 URL scheme + Router 的形式，根据不同的url路径，跳转不同的viewController控制器。这个负责跳转的模块被封装成一个类，目标控制器最终被当作block的参数返回。
这是非常灵活的一种跳转模式，但是没过多久就遇到了问题：

1 随着业务的发展，这个负责跳转的类中可能有几十个判断，每一个可点击的区域都有可能跳转到任意模块。最终导致这个类中代码冗余，难以维护，最重要是很low。
针对这个问题，可以将url和控制器的对应关系保存在一张plist表中。每次调用方法时通过获取控制器的名称，通过NSClassFromString(_:)方法获取。

2 此时又遇到第二个问题，就是项目中也许有的控制器是通过xib文件或者sb创建的。那么通过init方法创建控制器时无法正确获得控制器。
这个问题的解决其实非常容易，就是需要重写所有通过xib文件创建的控制器的init方法。保证在通过init方法创建时，分别调用他们本来的创建方式。

3 每当业务更新时，需要手动去修改url和控制器对应的plist文件，效率很低。
这个时候，你需要给项目的路由模块添加一个注册的机制，即通过开放的API修改本地的plist文件，达到可以动态添加和修改plist文件的目的。

最终的路由就保持上面的样子，不知道大家还有什么更好的优化方案。
当然，路由模式是有先天缺陷的，因为注册流程是必须的，但是又完全没有必要。其次是注册的内容常驻内存。最后是不符合组件化中“中间件为openUrl服务”的原则。

所以戴铭老师在文章中提到的“他认为好的架构”是CTMediator这种中介者模式。

2 中介者

我们先看一下下面的代码：

Person *person = [Person new];
// 1
[person speak:@"hi"];
// 2
[person performSelector:@selector(speak:) withObject:@"hi"];
// 3
NSString *string = @"hi";
NSMethodSignature *sign = [person methodSignatureForSelector:@selector(speak:)];
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:sign];
[invocation setTarget:person];
[invocation setSelector:@selector(speak:)];
[invocation setArgument:&string atIndex:2];
[invocation invoke];

这是3种不同的方法调用的方式。第三种就是中介者模式的核心原理。

为什么在setArgument:atIndex:时后者参数要传入 2？

void dynamicMethodIMP(id self, SEL _cmd, NSString *msg)
{
    // implementation ....
}

因为动态创建方法的第0个位置是self指针，第1个位置是sel选择器，第2个位置是传递参数，所以index是2。

在上面的基础上，CTMediator对传入的target和action加入容错处理：

- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget
{
    NSString *swiftModuleName = params[kCTMediatorParamsKeySwiftTargetModuleName];
    
    // generate target
    NSString *targetClassString = nil;
    if (swiftModuleName.length > 0) {
        targetClassString = [NSString stringWithFormat:@"%@.Target_%@", swiftModuleName, targetName];
    } else {
        targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
    }
    NSObject *target = self.cachedTarget[targetClassString];
    if (target == nil) {
        Class targetClass = NSClassFromString(targetClassString);
        target = [[targetClass alloc] init];
    }

    // generate action
    NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
    SEL action = NSSelectorFromString(actionString);
    
    if (target == nil) {
        // 这里是处理无响应请求的地方之一，这个demo做得比较简单，如果没有可以响应的target，就直接return了。实际开发过程中是可以事先给一个固定的target专门用于在这个时候顶上，然后处理这种请求的
        [self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
        return nil;
    }
    
    if (shouldCacheTarget) {
        self.cachedTarget[targetClassString] = target;
    }

    if ([target respondsToSelector:action]) {
        return [self safePerformAction:action target:target params:params];
    } else {
        // 这里是处理无响应请求的地方，如果无响应，则尝试调用对应target的notFound方法统一处理
        SEL action = NSSelectorFromString(@"notFound:");
        if ([target respondsToSelector:action]) {
            return [self safePerformAction:action target:target params:params];
        } else {
            // 这里也是处理无响应请求的地方，在notFound都没有的时候，这个demo是直接return了。实际开发过程中，可以用前面提到的固定的target顶上的。
            [self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
            [self.cachedTarget removeObjectForKey:targetClassString];
            return nil;
        }
    }
}

最终调用一个弹窗显示的代码：

[self performTarget:kCTMediatorTargetA
                 action:kCTMediatorActionShowAlert
                 params:paramsToSend
      shouldCacheTarget:NO];

理解原理之后，才能刚方便我们的使用，由于我并没有在真是项目中使用过这种模式。所以只能给大家提供几片文章参考：

iOS应用架构谈 组件化方案
在现有工程中实施基于CTMediator的组件化方案
CTMediator的Swift应用